The process should be agile and adaptable to problems.
Process adopted
for one project might be significantly different than a process adopted from
another project. (to the problem, the project, the team, organizational
culture). Among the differences are:
•the overall flow of activities, actions, and tasks and the interdependencies
among them
•the degree to which actions and tasks are defined within each framework
activity
•the degree to which work products are identified and required
•the manner which quality assurance activities are applied
•the manner in which project tracking and control activities are applied
•the overall degree of detail and rigor with which the process is described
•the degree to which the customer and other stakeholders are involved with
the project
•the level of autonomy given to the software team
•the degree to which team organization and roles are prescribed
Adapting a Process Model
•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.
•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.
Prescriptive and Agile Process Models
• 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).
The Essence of Practice
• 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?
Understand the Problem
• 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?
Plan the Solution
• 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?
Carry Out the Plan
•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?
Examine the Result
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)
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.
Hooker’s General Principles for Software Engineering
Practice: important underlying law
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
• 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.
• 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.
Software Myths Examples