Scribd
Upload
22 views12 pages

Prescriptive and Agile Process Models

Uploaded by

k9191173
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
22 views12 pages

Prescriptive and Agile Process Models

Uploaded by

k9191173
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 12

Prescriptive and Agile Process

Models
The prescriptive process models stress detailed
definition, identification, and application of process
activates and tasks. Intent is to improve system
quality, make projects more manageable, make
delivery dates and costs more predictable, and
guide teams of software engineers as they perform
the work required to build a system.
Unfortunately, there have been times when these
objectives were not achieved. If prescriptive models
are applied dogmatically and without adaptation,
they can increase the level of bureaucracy.
Prescriptive and Agile Process
Models
• Agile process models emphasize project
“agility” and follow a set of principles that lead
to a more informal approach to software process.
It emphasizes maneuverability and adaptability.
It is particularly useful when Web applications
are engineered.
The Essence of Practice
• How does the practice of software engineering
fit in the process activities mentioned above?
Namely, communication, planning, modeling,
construction and deployment.
• George Polya outlines the essence of problem
solving, suggests:
1.Understand the problem (communication and analysis).
2.Plan a solution (modeling and software design).
3.Carry out the plan (code generation).
4.Examine the result for accuracy (testing and quality
assurance).
Understand the Problem
• Who has a stake in the solution to the problem?
That is, who are the stakeholders?
• What are the unknowns? What data,
functions, and features are required to
properly solve the problem?
• Can the problem be compartmentalized? Is it
possible to represent smaller problems that
may be easier to understand?
• Can the problem be represented graphically?
Can an analysis model be created?
Plan the Solution
• Have you seen similar problems before? Are there
patterns that are recognizable in a potential
solution? Is there existing software that implements
the data, functions, and features that are required?
• Has a similar problem been solved? If so, are elements
of the solution reusable?
• Can subproblems be defined? If so, are solutions
readily apparent for the subproblems?
• Can you represent a solution in a manner that leads to
effective implementation? Can a design model be
created?
Carry Out the Plan
• Does the solutions conform to the plan? Is
source code traceable to the design model?
• Is each component part of the solution
provably correct? Has the design and code
been reviewed, or better, have correctness
proofs been applied to algorithm?
Examine the Result
• Is it possible to test each component part of the
solution? Has a reasonable testing strategy
been implemented?
• Does the solution produce results that conform
to the data, functions, and features that are
required? Has the software been validated
against all stakeholder requirements?
Hooker’s General Principles for Software
Engineering Practice: important underlying
law
Help you establish mind-set for solid software
engineering practice (David Hooker 96).
•1: The Reason It All Exists: provide values to users
•2: KISS (Keep It Simple, Stupid! As simple as possible)
•3: Maintain the Vision (otherwise, incompatible
design)
•4: What You Produce, Others Will Consume (code
with concern for those that must maintain and
extend the system)
Hooker’s General Principles for Software
Engineering Practice: important underlying
law

•5: Be Open to the Future (never design


yourself into a corner as specification and
hardware changes)
•6: Plan Ahead for Reuse
•7: Think! Place clear complete thought before
action produces better results.
Software Myths
Erroneous beliefs about software and the process that is
used to build it.
•Affect managers, customers (and other non-technical
stakeholders) and practitioners
•Are believable because they often have elements of
truth,
but …
•Invariably lead to bad decisions,
therefore …
•Insist on reality as you navigate your way through
software engineering
Software Myths Examples
• Myth 1: Once we write the program and get it to work, our
job is done.
• Reality: the sooner you begin writing code, the longer it will
take you to get done. 60% to 80% of all efforts are spent
after software is delivered to the customer for the first time.

• Myth 2: Until I get the program running, I have no way of


assessing its quality.
• Reality: technical review are a quality filter that can be used
to find certain classes of software defects from the
inception of a project.
Software Myths Examples
• Myth 3: software engineering will make us create
voluminous and unnecessary documentation and will
invariably slow us down.
• Reality: it is not about creating documents. It is about
creating a quality product. Better quality leads to a
reduced rework. Reduced work results in faster delivery
times.

• Many people recognize the fallacy of the myths.


Regrettably, habitual attitudes and methods foster
poor management and technical practices, even
when reality dictates a better approach.

You might also like