SYSTEMS ANALYSIS project

profiledaven9947
03_SystemsAnalysis-Fall2019-Week31.pdf

9/18/19

1

ISMM1-UC 752: SYSTEMS ANALYSIS

Fall 2019 – Lecture 3 Instructor: Dr. Antonios Saravanos

Incremental Model

• Development and delivery of functionality occurs in increments

• Works well when requirements are known beforehand

• Projects are broken down into sub- projects

Source: Project Management for IT-Related Projects (p. 18)

2

9/18/19

2

Incremental Cycle

Incremental Model

9/18/19

3

Iterative Model

• Ideal for situations where not all requirements are known up front

• Need for development to begin as soon as possible

Source: Project Management for IT-Related Projects (p. 19) 5

Iterative Cycle

9/18/19

4

Iterative Model

Incremental vs. Iterative

• Incremental fundamentally means add onto. Incremental development helps you improve your process.

• Iterative fundamentally means re- do. Iterative development helps you improve your product.

9/18/19

5

• Is iterative and incremental the same thing?

Incremental vs. Iterative

Source: http://www.applitude.se/images/inc_vs_ite.png

10

9/18/19

6

Iterative and Incremental Combined

A Simple Software Development Method

• Initial Planning

• Design • Implementation • Testing

Source: Making Things Happen: Mastering Project Management (p. 30)

12

n

9/18/19

7

Alistair Cockburn • What’s Alistair’s take on Iterative vs. Incremental?

Incremental vs. Iterative • in incremental development, you do each of those

activities multiple times … that is, you go around the requirements – design – programming – testing – integration – delivery cycle multiple times. You “iterate” through that cycle multiple times. (“iterate” – get it? sigh…)

• in iterative development, you also do each of those activities multiple times … you go around the requirements – design – programming – testing – integration – delivery cycle multiple times. You “iterate” through that cycle multiple times. By Gummy! Both of those are “iterative” development! WOW!

9/18/19

8

Incremental vs. Iterative (cont’d)

• Of course, the $200,000 question is, do you repeat the cycle “on the same part of the system you just got done with” or “on a new part of the system”? How you answer that question yields very different results on what happens next on your project.

Roles

• Product Owner (Business) – Represents the customer – Controls the product backlog – Signs off on deliverables

• The Scrum Master – Ensures scrum values are understood and kept – Tracks progress and finds ways to overcome obstacles

• The Development Team – The people actually responsible for delivering the system – Self-organizing unit – Members of the team are generalists not specialists

• Cross functional (Each member of the team knows all aspects of the product that is being developed)

16

9/18/19

9

The Agile System Development Methodology

17

Manifesto for Agile Software Development

18

9/18/19

10

Manifesto for Agile Software Development

Source: http://www.applitude.se/images/inc_vs_ite.png

19

Manifesto for Agile Software Development

Source: http://www.applitude.se/images/inc_vs_ite.png

20

9/18/19

11

Principles Behind the Agile Manifesto

Source: http://agilemanifesto.org/principles.html

21

Principles Behind the Agile Manifesto

Source: http://agilemanifesto.org/principles.html

22

9/18/19

12

Principles Behind the Agile Manifesto

Source: http://agilemanifesto.org/principles.html

23

Agile methods

• Dissatisfaction with the overheads involved in design methods led to the creation of agile methods. These methods: – Focus on the code rather than the design; – Are based on an iterative approach to software development; – Are intended to deliver working software quickly and evolve this

quickly to meet changing requirements. • Agile methods are probably best suited to

small/medium-sized business systems or PC products.

9/18/19

13

Principles of agile methods

Principle Description

Customer involvement The customer should be closely involved throughout the development process. Their role is provide and prioritise new system requirements and to evaluate the iterations of the system.

Incremental delivery The software is developed in increments with the customer specifying the requirements to be included in each increment.

People not process The skills of the development team should be recognised and exploited. The team should be left to develop their own ways of working without prescriptive processes.

Embrace change Expect the system requirements to change and design the system so that it can accommodate these changes.

Maintain simplicity Focus on simplicity in both the software being developed and in the development process used. Wherever possible, actively work to eliminate complexity from the system.

Problems with agile methods

• It can be difficult to keep the interest of customers who are involved in the process.

• Team members may be unsuited to the intense involvement that characterizes agile methods.

• Prioritizing changes can be difficult where there are multiple stakeholders.

• Maintaining simplicity requires extra work. • Contracts may be a problem as with other approaches to

iterative development.

9/18/19

14

The Paradigm Shift

27

Relationship Between Agile Values, Principles, and Practices

Source: http://i.msdn.microsoft.com/dynimg/IC511953.jpg

28

9/18/19

15

Popular Agile Software Development Frameworks

• Scrum • Extreme programming (XP) • Crystal • Kanban (???) • Dynamic Systems Development Method (DSDM) • Feature-Driven Development (FDD)

• Source: Pro Agile .NET Development with Scrum (p. 8-11)

29

Principles of Scrum

• Regularly deliver value • Adjust process according to results • Allow business to change their mind when needed • Allow the development team the time to complete their commitments to the

business

30

9/18/19

16

Scrum Values

• Commit to the goal • Focus on completing your commitment • Be open and share with your team • Respect your team • Have the courage to act for the best interests of achieving your goal

31

Roles

• Product Owner (Business) – Represents the customer – Controls the product backlog – Signs off on deliverables

• The Scrum Master – Ensures scrum values are understood and kept – Tracks progress and finds ways to overcome obstacles

• The Development Team – The people actually responsible for delivering the system – Self-organizing unit – Members of the team are generalists not specialists

• Cross functional (Each member of the team knows all aspects of the product that is being developed)

32

9/18/19

17

Scrum Values

• Commit to the goal • Focus on completing your commitment • Be open and share with your team • Respect your team • Have the courage to act as necessary

33

Scrum Values

• Commit to the goal • Focus on completing your commitment • Be open and share with your team • Respect your team • Have the courage to act as necessary

34

9/18/19

18

The Scrum Process Lifecycle

Source: Pro Agile .NET Development with Scrum (p.14)

35

Product Backlog

• An ordered list of desired product functionality

36

9/18/19

19

Sprint

• Scrum is comprised of a series of time blocks called sprints (timeboxes) • The goal of a sprint is to deliver working software • The duration of a sprint is typically two to four weeks in length • Sprints are isolated from change and represent a commitment by both the

business and the developer

37

Sprint Backlog

• A list of tasks to be completed during the sprint • A subset of the product backlog

38

9/18/19

20

Daily Scrum Meetings

• Team meets daily to touch base • Meetings are usually short short (15-20 minutes in length) • Provide an opportunity to discuss what has happened since the last meeting • What we will take place next • Any development obstacles

39

Sprint Review

• A meeting during which the team presents the increment that has been built during the sprint

• Time of meeting varies on perspective but can range form from 2 to 4 hours

40

9/18/19

21

Sprint Retrospective

• Traditionally takes place after the sprint review • Provides an opportunity to go over the sprint and reflect on activities • Provides an opportunity to think about what the team should:

– start doing – stop doing – continue doing

• The meeting should be comprised of the: – (entire) development team – scrum master – product owner – Sprint retrospectives usually last for about an hour but duration varies

according to need

41