Lecture 2 Slides 6

8/16/2019 Lecture 2 Slides 6

1/14

1

The Best Buddy !!!

2

Modelling the Process and LifeCycle

Software development usually involves thefollowing stages:

• Requirements analysis and definition• System design• Program design• Program implementation (writing the program)• Unit testing• Integration testing• System testing• System delivery• Maintenance

3

What is a process?

• A series of steps involving activities, constraintsand resources that produce an intended output ofsome kind

• Characteristics of a process:

– prescribes all of the major process activities

– uses resources, subject to a set of constraints (such as aschedule), and produces intermediate and final results

– may be composed of sub-processes that are linked insome way.

– each process activity has an entry and exit criteria , so weknow when each activity begins and ends

4

What is a process? (continued )

– activities are organised in a sequence, so that it isclear when one activity is performed relative tothe other activities

– a set of guiding principles that explain the goals

of each activity

– constraints or controls may apply to an activity,

resource or product.

• e.g. budget or schedule may constrain length of time

activity may take

5

Reasons for modelling a process• Common understanding of the activities, resources and

constraints

• Helps in the finding of inconsistencies, redundancies and

omissions

• Help evaluate candidate activities for their

appropriateness in meeting the goals, such as building

high-quality software.

• Every process should be tailored for the special situation

in which it will be used. Building a model helps the

team understand where that tailoring is to occur

6


2/14

7 8

Waterfall model

9 10

11 12

Waterfall model: advantages

• Very useful in helping developers layout(very high-level view) what they need todo

• Simplicity – makes it easy to explain tocustomers (who are not familiar withsoftware developers)

– Explicitly states which intermediate productsare necessary in order to begin next stage


3/14

13

Waterfall model: disadvantages

• Failure to treat software as a problem solving process.Software is a creation process not a manufacturing

process. Software evolves as the problem isunderstood and the alternatives are evaluated.

• In particular, creation involves trying a little of this or

that, developing and evaluating prototypes, assessing

the feasibility of requirements, contrasting several

designs, learning from failure and eventually settling

on a satisfactory solution to the problem

14

Waterfall model: disadvantages

• It provides no guidance of how each activitytransforms one artefact into another, such asrequirements to design. Thus the model providesno guidance to managers and developers on how tohandle changes to products and activities that arelikely to occur during development.

If requirements change during coding, what changes

do we make to design and code?

15 16

17 18

Software development in reality


4/14

19 20

21

Process models

The software development process can help control thethrashing by including activities and sub-processes thatenhance understanding.

Prototyping is such a sub-process; a prototype is a partiallydeveloped product that enables customers anddevelopers to examine some aspect of the proposedsystem and decide it is suitable or appropriate for the

finished product.

22

23

Incremental model

In the incremental model, the system asspecified in the requirements is partitionedinto sub-systems by functionality. Thereleases are defined by beginning with onesmall functional sub-system and then addingfunctionality with each new release.

24

Iterative model

This model delivers a full system at the very beginning and then changes the functionalityof each sub-system with each new release.


5/14

25

Phased development model

26

Phased development model

This is used to reduce cycle time. The system is

designed so that it can be delivered in pieces,enabling users to have some functionalitywhile the rest is being developed.

There are usually two systems functioning in parallel: the production system and thedevelopment system

27

Phased development: advantages

• Training can begin on an early release. Thetraining process allows developers toobserve how certain functions are executed,suggesting enhancements for later releases.

In this way, the developers can be very

responsive to the users

28

Phased development: advantages

• Markets can be created early for functionalitythat has never before been offered

• Frequent releases allow developers to fix

unanticipated problems as they are reported

• The development team can focus on different

areas of expertise with different releases.

29 30


6/14

31 32

33

Prototyping model

34

Prototyping model

Prototyping can be the basis of an effective process model. This model allows all or part ofthe system to be constructed quickly tounderstand or clarify issues.

The overall goal is to reduce risk and uncertainty

in development.

35 36


7/14

37 38

39


40

Question

Should a development organisationadopt a single process model for allof its software development?

Discuss the pros and cons.

41

Answer

Pros:

• Standardization of training, terminology, thecollection of process metrics, planning andestimation. Works well if the projects arevery similar in nature.

Cons:

• Adopting a single standard process mayunnecessarily constrain some projects fromusing the process that is best suited to the problem and the solution.

42

Question

Suppose your contract with thecustomer specifies that you use a

particular software development process.

How can work be monitored toenforce the use of this process?


8/14

43

Answer Conformance to a particular process is often checked withthe use of milestones.

That is, the process is defined in such a way that there aretangible products in the process whose existence indicatesthat particular process steps have been carried out.

For example, when using the waterfall process; Theseintermediate products, or milestones, could be arequirements document, a design document, the codeitself, test documents etc.

The timing of these products indicate whether or not the process was being followed as planned. 44

Answer (continued )

Another way to monitor use of a process is bymeasuring effort. Developers working on the project could be required to report the effortthey spent on different process activities. Bytracking when effort is spent on whichactivities, progress through the steps of the process could be monitored.

45 46

The Rational Unified Process

•a process framework that can be adapted andextended to suit the needs of an adoptingorganization.

•general and comprehensive enough to be used"as is," i.e., out-of-the-box, by many small-to-medium software development organizations,especially those that do not have a very strong process culture.

47

The Rational Unified Process

•Can also modify, adjust, and expand the RUP toaccommodate the specific needs, characteristics,constraints, and history of its organization, culture, anddomain.

•Process should not be followed blindly, generatinguseless work and producing artefacts that are of little

added value.

•Instead, must be made as lean as possible while still

fulfilling its mission to help developers rapidly produce

predictably high-quality software.

48

The RUP Captures SoftwareDevelopment Best Practices

•RUP captures many of modern softwaredevelopment's best practices in a form suitablefor a wide range of projects and organizations:

– Develop software iteratively.

– Manage requirements.

– Use component-based architectures.

– Visually model software.

– Continuously verify software quality.

– Control changes to software.


9/14

49 50

51 52

53

Rational Unified Process

As in the text book54


10/14

55


56

Develop Software Iteratively

•Most software teams still use a waterfall process fordevelopment projects, completing in strict sequence

the phases of requirement analysis, design,implementation/integration, and test.

– idles key team members for extended periods

– defers testing until the end of the project lifecycle, when

problems tend to be tough and expensive to resolve

– pose a serious threat to release deadlines

•By contrast, RUP represents an iterative approach

that is superior

57

Manage Requirements

Requirements management is a systematicapproach to eliciting, organising,communicating, and managing the changingrequirements of a software-intensive system orapplication.

58

Continuously Verify Quality

•There is no worker in charge of quality in the RUP

– Because quality is not added to a product by a few people.

•Instead, quality is the responsibility of every member ofthe development organization.

•In software development, our concern about quality isfocused on two areas:

– product quality

– process quality.

59

Continuously Verify Quality(continued )

• Product quality -- The quality of the principal product being produced (the software or system)and all the elements it comprises (for example,components, subsystems, architecture, and so on).

• Process quality -- The degree to which anacceptable process (including measurements and

criteria for quality) was implemented and adhered

to during the manufacturing of the product.

60

Agile Methods

• Agile manifesto focuses on four simplevalue statements, which defines preferences:

– Individuals and interactions over processes andtools

– Working software over comprehensivedocumentation

– Customer collaboration over contractnegotiation

– Respond to changes over following a plan


11/14

61

Agile Processes

• Extreme Programming(XP)• Crystal

• Scrum

• Adaptive Software Development

62

Extreme Programming(XP)

• Leveraging the creativity of developers andminimising the amount of administrationoverhead

• Emphasises four characteristics of agility:

– Communication

– Simplicity

– Courage

– Feedback

63

XP (continued)

• Communication

– Continual interchange between customers anddevelopers

• Simplicity

– Encourages developers to select the simplest design orimplementation to address the needs of the customer

• Courage

– Commitment to delivering functionality early and often

• Feedback

– Loops are built into various activities duringdevelopment process64

Crystal

• Collection of approaches based on the notion that

every project needs a different set of policies,

conventions and methodologies

• Suggests the following:

– quality of the projects and processes improves as the

quality of the people involved improves

– Productivity increases through better communication

and frequent delivery because there is less need for

intermediate products

65

Scrum

• Uses iterative development, where each 30-day

iteration is called a “sprint”

• During a “sprint”, implement the product’s backlog of prioritised requirements

• Multiple self-organising and autonomous teams

implement product increments in parallel

• Coordination is done at a brief daily status

meeting called a “scrum”

66

Adaptive Software Development

• has six basic principles:

• A mission that acts as a guideline

• Features are viewed as the crucial point of thecustomer value

• Iteration is important

• Change is embraced

• Fixed delivery times

• Risk is embraced


12/14

67

ASD (continued)

• A mission that acts as a guideline

– setting out the destination but not prescribing how to

get there

• Features are viewed as the crucial point of the

customer value

– so the project is organised around building components

to provide features

• Iteration is important

– so redoing is as critical as doing

68

ASD (continued)

• Change is embraced

– so that change is viewed not as a correction but as an

adjustment to the realities of software development

• Fixed delivery times

– force the developers to scope down the requirements

essential for each version produced

• Risk is embraced

– so that the developer tackles the hardest problems first

69

Do you still think this is your Best

Buddy ???? 70

71 72


13/14

73 74

75 76

77 78


14/14

79 80

81

www.inderscience.com/ijecrm

Then choose Volume 1, Issue 1

Full paper

Can be

downloaded

82

End of Lesson II

Thank you

Documents

Lecture 2 Slides 6