1. IS2210: Systems Analysis and Systems Design and Change Email: cathal.doyle@umail.ucc.iecathal.doyle@umail.ucc.ie Twitter: @InstCathalDoyle@InstCathalDoyle Website: www.cathaldoyle.comwww.cathaldoyle.com

2. Learning Outcomes O Understand why systems analysis and design is a module O Understand the Agile Lifecycle O Understand the differences between traditional and agile methods

3. Why SAD? O Why do you think you are doing this module? O Has anyone seen any benefits? O What are the negatives?

4. What have we looked at? O SDLC O Traditional Method – Waterfall O What else is there?

5. Types of SDLC O Waterfall Model O Spiral Model O V-Model Traditional Methods Agile Methods O Extreme Programming (XP) O Scrum O Adaptive Software Development O Dynamic Systems Development Method (DSDM) O Feature Driven Development

6. 6 Analyst Edward Cost of change Promised date We are already running late. I need to meet my date. We worked hard to prevent change at the start. W HY DO WE NEED A GILE ANYWAY ? Edwards’s Customer © Vision Consulting

7. 7 Analyst Edward Edwards’s Customer Cost of change We are already running late. I need to meet my date. We worked hard to prevent change at the start. W HY DO WE NEED A GILE ANYWAY ? Change & Rework happens at the most expensive time Spec signed off here © Vision Consulting Promised date

8. 8 Learning Curve Change! Our spec was a guess We learn by doing the project We need the best product Edwards - Customer Spec signed off here Analyst Edward © Vision Consulting Promised date

9. Edward’s Customer Out of hundreds of projects, there is no case in which requirements remained stable throughout the design - Reinertson (1998) on Product Development A typical software project experiences a 25% change in requirements - Boehm and Papaccio (1988) on Software Development Medium to Large projects (1000+ function points) experience 25 – 35% requirements change - Jones (1997) on Software Development Conclusion: We can’t successfully prevent change Learning Curve Spec signed off here This learning causes change Change! Our spec was a guess We learn by doing the project We need the best product Analyst Edward © Vision Consulting Promised date

10. Who’s to blame? -The customer?  -The project manger?  -The way we build software? Edward’s Customer Analyst Edward WHO’S TO BLAME? © Vision Consulting

11. Why Do Projects Fail? O Lack of sponsor involvement O Poor scope management O Poor planning

12. Interesting Figures O IT projects have a history of failure O 30-40% of systems projects fail prior to completion O Failed systems in the US cost $100 billion per year

13. What does this mean? O Are traditional methods useless? O They leave little room for change O Is there too much documentation involved?

14. A Possible Solution… O Agile software development O The aim is to develop software in iterations which last 1-4 weeks O Each of these iterations can be seen as miniature software projects

15. The Agile Software Development Manifesto On February 11-13, 2001 Agile Alliance, (formed of software practitioners and consultants), formed and produced a Manifesto for Agile Software Development Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over rigid contracts Responding to change over following a plan

16. People over Process O Human interactions are more important than the company’s processes and tools O Close team relationships O Close working environment

17. Working Software O Frequent output of working, tested software O Keep It Simple Stupid (KISS) O The less documentation the better

18. Relationship With Customer O Co-operation with the customer over strict contracts O Deliver software quickly so customers can see it O Reduce the risk of not meeting the terms of contract

19. Responding to Change O Contracts must be worded so as to allow change O Team must be competent to make changes O Customers are part of the team so they are aware of, and sanction, changes

20. So what makes an agile method? O Incremental O Involves delivering releases frequently and with a few enhancements O Cooperative O Refers to a close interaction between customers and developers

21. O Straightforward O The method itself is easy to learn, modify, and is well documented O Adaptive O We can still change requirements even late in the development process

22. Agile Methods O Extreme Programming (XP) O Scrum O Adaptive Software Development (ASD) O Crystal Clear and Other Crystal Methodologies O Dynamic Systems Development Method (DSDM) O Feature Driven Development

23. Agile Methods vs Traditional Methods O Agile methods emphasize real-time communication, preferably face-to-face, over written documents O Agile methods rely on the close collaboration of activity engaged individuals with ordinary talents and has the ability to flexibly schedule the implementation of functionality, responding to changing business needs O The customer is on-site and part of the development team

24. Values and Principles O Communication O Simplicity O Feedback O Courage Agile modelers possess the self-confidence to allow their customers to question, critique, and sometimes complain about the system under development. Analysts learn from their customers, who have been in business a long time.

25. 5 Agile Principles for Systems Analysts

26. XP P ROCESS L IFECYCLE The XP lifecycle consists of 5 phases: Exploration, Planning, Iterations to Release, Productionizing, Maintenance and Death Pair Programming Test Collective codebase Stories Regular updates Stories for the next iteration Priorities Effort estimates AnalysisDesign Planning for testing Testing FeedbackContinuous Integration Continuous Review Small Release Updated Releases Final Release Customer Approval Exploration Phase Planning PhaseIterations to Release Phase Productionizing Phase Maintenance Phase Death Phase

27. Thanks O Any Questions?