1. Final
Proposal
Agile vs. Prescriptive
Software Engineering 1
Muhammad Muzammil
BSCS 4th B
Reg # 17104/Aut-07/M
Submitted to: Mr. Abdul Rasheed
Federal Urdu University, of Arts, Science & Technology
G-7/1, Near Zero Point, Islamabad

2. 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

3. 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?
Page 3

4. They may aim at:
• 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

5. 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.
Page 5

6. • 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.
• 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
Page 6

7. 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…
• 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.
Page 7

8. 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
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
Wate
r fall
XP,ASD
Agile
More value,
Lean Thinking 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.
Page 8

9. 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.
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.
Page 9

10. 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;
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.
Page 10

11. 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.
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

12. 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