Agile vs. PrescriptiveSoftware Engineering 1

Submitted to: Mr. Abdul Rasheed

Final Proposal

Federal Urdu University, of Arts, Science & TechnologyG-7/1, Near Zero Point, Islamabad

Muhammad Muzammil

BSCS 4th B

Reg # 17104/Aut-07/M

Abstract:

It is a very glad full moment that I am submitting my final

proposal documentation. It is not easy and first attempt work to complete this,

but in the whole time my respected teacher MR. Abdul Rasheed has given me

full of confidence and some important guideline to complete this document.

So this is the result of all of his effort. According to me this topic is quite

difficult but I enjoy a lot.

Muhammad Muzammil

Table of Contents:

Software Processes.........................................................................................................................3

Prescriptive Approach....................................................................................................................3

Agile...............................................................................................................................................4

Agile VS Prescriptive.......................................................................................................................5

Principle Based VS Rule Based........................................................................................................6

To be Prescriptive or Less prescriptive............................................................................................6

Prescriptive VS Agile Process Models..............................................................................................7

Waterfall VS Agile Methodology.....................................................................................................7

References ...................................................................................................................................12

Agile VS Prescriptive

Page 2

Software Processes:

A set of interrelated activities, which transform inputs into outputs

A function that must be performed in the software life cycle.

A Process is composed of activities

Definition of Prescriptive

Indicating how things should be , rather than how things are

Making or giving injunctions, directions, laws, or rules

A prescriptive process model is a model that describes "how to do" according to a

certain software process system.

Prescriptive Process Models:

A prescriptive model prescribes how a new software system should be

developed. Prescriptive models are used as guidelines or frameworks to organize and

structure how software development activities should be performed, and in what order.

Typically, it is easier and more common to articulate a prescriptive lifecycle model for how

system should be developed. This is possible since most such models are intuitive or well

reasoned. This means that many idiosyncratic details that describe how a software system is

built in practice can be ignored, generalized, or deferred for later consideration. This, of

course, should raise concern for the relative validity and robustness of such life cycles models

when developing different kinds of applications systems, in different kinds of development

settings, using different programming languages, with differentially skilled staff, etc.

However, prescriptive models are also used to package the development tasks and techniques

for using a given set of software engineering tools or environment during a development

project.

Within prescriptive software process models, any explicit element which

constraints the process performance.

People dealing with software processes may adopt a prescriptive attitude of mind.

They define desired processes to answer the question "how software should be developed?

They may aim at:

Page 3

Guiding Software process performers (developers, managers,) receive indirect

support through information which helps them to perform their work, such as the

current status of the process, the appropriate next steps to be executed, the decision

points and their meanings, etc. Guidance is provided through manual or mechanical

interpretation of software process descriptions simultaneously and synchronously with

the actual software process performance.

Enforcing Software process performers (developers, managers, ...) receive direct

support .through enact able software process descriptions which are mechanically

interpreted by process engines within a process-centered software engineering

environment, to orchestrate the performance of the actual development and to

automatism it as far as possible. What cannot be programmed for machine

interpretation is left for humans to perform; for instance, the support system can await

represent able results of the intermediate human process.

Definition of Agile:

Characterized by quickness, lightness, and ease of movement; nimble.

Mentally quick or alert: an agile mind

Agility:

o Agility is the ability to change the body's position efficiently, and requires the

integration of isolated movement skills using a combination of balance, 

coordination,  speed,  reflexes, strength, endurance, and stamina.

o In sports, agility is described in terms of response to an opposing player,

moving target, as seen in field sports and racket sports. Sheppard and Young

(2006) define agility as "a rapid whole body movement with change of

velocity or direction in response to a stimulus."

Page 4

o In business, agility means the capability of rapidly and cost efficiently

adapting to changes. Recently agility has been applied e.g. in the context

of agile software development and agile enterprise

Need for agile approach:

In certain business environment, it is often difficult (or impossible) to predict as to how a

software product will evolve over time

Market conditions change

Users needs evolve

Competitive forces prevail

Technology keeps changing

Under the above mentioned environment, it is not possible to define all the software

requirements in early stages of the project.

The developer, therefore, needs to be agile enough to respond to this fluid

business environment.

Weakness of prescriptive approaches includes:

Emphasis on discipline (not a strong point for people)

Lack of realization that all developers are not alike

Agile approaches, however, are not applicable to all projects, products, people, and situations.

Agile vs. prescriptive processes overview:

In general agile method promotes empirical rather than defined processes, a

categorization used by industrial process experts.

A defined process (also known as a prescriptive process) has many predefined and

ordered activities to be followed during development.

Defined process is suitable for predictable manufacturing domains.

Page 5

Empirical processes are used for high change and unstable domains: rather than many

sequenced activities, they are based on frequent measurement and dynamic response

to variable events.

For example, scrum is silent on the activities of iteration, other than the daily scrum

meeting as the measurement and response mechanism. The up, on the other hand,

strikes a middle way; it list common activities (e.g. write release notes), but the team

is welcome to ignore or do them in any order.

Agile methodologies understand that the degree of “method weight” and predefinition

of ordered activities are functions of the project type. An agile method or project lies

on a continuum of more or less empirical, driven by need. A medical device under

FDA approval requires more formal, predefined activities.

Principle based vs Rule-based:

Agile methods are more principle-based than rule-based. Rather than a predefined

set of rules regarding the many roles, team organization, responsibilities, relationships, and

activities, the team and manager are primarily guided by the principles embodied in the agile

manifesto and principles. Agile project management is more than a set of practices – it is a

mindset.

To be prescriptive or less prescriptive:

Generic framework for software process encompasses the following:

Communication

planning

modeling

construction

deployment

Prescriptive process models advocate an orderly approach to software engineering.

In reality, these models “need to be adapted” to meet the unique needs of a

project.

An old contradictory questions about software development…

Page 6

If a prescriptive process models strive for structure and other, are they

inappropriate for a software (creative) world?

If “less structures” models are used for software development will it be possible to

coordinate and manage this work?

There are no easy answers to these questions.

Each approach may be appropriate under certain circumstances.

Note: When in doubt, be more prescriptive.

Prescriptive vs. agile process models:

Prescriptive models:

They are indicated

Facilitating planning

Improving system quality

Improving control

Guiding project teams

If they are applied dogmatically and without adaption, they tend to be bureaucratic.

Agile models:

They are tending to be informal.

They are emphasizing on maneurability, adaptability, and speed.

They are appropriate for many types of projects, e.g. web based development.

Note: Excessively agile processes may be as risky as the excessively rigid processes

Waterfall VS Agile Methodology:

There is no IT meeting that does not talk and debate endlessly about Waterfall vs.

Agile development methodologies.  Feelings run strong on the subject with many

Page 7

considering Agile ‘so of the moment’, just so right, while Waterfall is thought to be

passé!  But, before deciding which is more appropriate, it is essentially important to provide a

little background on both.

Prescriptive

More value,

Idea based

Waterfall

A classically linear and sequential approach to software design and systems development,

each waterfall stage is assigned to a separate team to ensure greater project and deadline

control, important for on-time project delivery.  A linear approach means a stage by stage

approach for product building, e.g.

1.      The project team first analyses, then determining and prioritizing business requirements /

needs.

2.      Next, in the design phase business requirements are translated into IT solutions, and a

decision taken about which underlying technology i.e. COBOL, Java or Visual Basic, etc. etc.

is to be used.

Page 8

Lean Thinking

Agile

XP,ASD

Water fall

3.      Once processes are defined and online layouts built, code implementation takes place.

4.      The next stage of data conversion evolves into a fully tested solution for implementation

and testing for evaluation by the end-user.

5.      The last and final stage involves evaluation and maintenance, with the latter

ensuring everything runs smoothly.

However, in case a glitch should result, changing the software is not only a practical

impossibility, but means c.  That’s Waterfall for us! Now, as for minimal risk Agile, it is a

low over-head method that emphasizes values and principles rather than

processes.  Working in cycles i.e. a week, a month, etc., project priorities are re-evaluated and

at the end of each cycle.  Four principles that constitute Agile methods are:

1.      The reigning supreme of individuals and interactions over processes and tools.

2.      As does, working software over comprehensive documentation.

3.      Likewise, customer collaboration over contract negotiation.

4.      And again, responding to change over plan follow-throughs.

To summarize the difference between the two, one can say the classic waterfall method

stands for predictability, while Agile methodology spells adaptability.  Agile methods are

good at reducing overheads, such as, rationale, justification, documentation and meetings,

keeping them as low as is possible.  And, that is why Agile methods benefit small teams with

constantly changing requirements, rather more than larger projects.

Agile, based on empirical rather than defined methods (Waterfall) is all about light

maneuverability and sufficiency for facilitating future development.  By defined methods

what one means is that one plans first and then enforces these plans.  However, Agile

methods involve planning what one wants and then adapting these plans to the

results.  Extreme Programming (XP) is an excellent example of Agile methodology i.e.:

1.      Communication between customers and other team members;

2.      Simple, clean designs;

Page 9

3.      Feedback given on Day 1 of software testing;

4.      Early delivery and implementation of suggested changes. 

Agile methodology means cutting down the big picture into puzzle size bits, fitting them

together when the time is right e.g. design, coding and testing bits.  So, while there are

reasons to support both the waterfall and agile methods, however, a closer look clarifies why

many software and web design firms make the more appropriate choice of employing Agile

methodology.  The following points define to choose Agile methodology over the Waterfall

method.

1. Once a stage is completed in the Waterfall method, there is no going back, since

most software designed and implemented under the waterfall method is hard to change

according to time and user needs.  The problem can only be fixed by going back and

designing an entirely new system, a very costly and inefficient method. Whereas, Agile

methods adapt to change, as at the end of each stage, the logical program, designed to cope

and adapt to new ideas from the outset, allows changes to be made easily.  With Agile,

changes can be made if necessary without getting the entire program rewritten.  This

approach not only reduces overheads, it also helps in the upgrading of programmers.

2.  Another Agile method advantage is one has a launch able product at the end of each

tested stage.  This ensures bugs are caught and eliminated in the development cycle, and the

product is double tested again after the first bug elimination.  This is not possible for

the Waterfall method, since the product is tested only at the very end, which means any

bugs found results in the entire program having to be re-written.

3. Agile’s modular nature means employing better suited object-oriented designs and

programs, which means one always has a working model for timely release even when it

does not always entirely match customer specifications.  Whereas, there is only one main

release in the waterfall method and any problems or delays mean highly dissatisfied

customers.

4. Agile methods allow for specification changes as per end-user’s requirements,

spelling customer satisfaction.  As already mentioned, this is not possible when the

waterfall method is employed, since any changes to be made means the project has to be

started all over again.

Page 10

5. However, both methods do allow for a sort of departmentalization e.g. in waterfall

departmentalization is done at each stage.  As for Agile, each coding module can be

delegated to separate groups. This allows for several parts of the project to be done at the

same time, though departmentalization is more effectively used in Agile methodologies.

 In conclusion, though on the plus side, waterfall’s defined stages allow for thorough

planning, especially for logical design, implementation and deployment, Agile methodology

is a sound choice for software development and web design projects.  More and more firms

are becoming Agile

Most agile methods share iterative development's emphasis on building releasable

software in short time periods. Agile methods differ from iterative methods in that their time

period is measured in weeks rather than months. Most agile methods also differ by treating

their time period as a strict time box.

Page 11

References:

[1] www.eflnet.com/vocab/advvoclist25.php

[2] http://www.answers.com/topic/prescriptive

[3]

http://www.informatik.uni-bremen.de/gdpa/def/def_p/PRESCRIPTIVE_PROCESS_MODEL

.htm

[4] http://www.answers.com/topic/prescriptive

[5] http://en.wikipedia.org/wiki/Agility

[6] http://books.google.com.pk/books?id=l9iskVrsP28C&pg=PA150&dq=Prescriptive+vs+agile#PPA149,M1

[7] http://agileintro.wordpress.com/2008/01/04/waterfall-vs-agile-methodology/

[8] http://www.coderanch.com/t/130626/Agile-Other-Processes/Agile-Vs-Iterative

Page 12