PRINCIPLES THAT GUIDE EACH FRAMEWORK ACTIVITY

Communication Principles
Effective communication (among technical peers, with the
customer and other stakeholders, and with project
managers) is among the most challenging activities.
many of the principles apply equally to all forms of
communication that occur within a software project
Principle 1. Listen. Try to focus on the speaker’s words, rather
than formulating your response to those words.
Ask for clarification if something is unclear, but avoid
constant interruptions
Principle 2. Prepare before you communicate.
Spend the time to understand the problem before you meet
with others.
If necessary, do some research to understand business
domain jaPrinciple 3. Someone should facilitate the activity.
Principle 3. Someone should facilitate the activity
Every communication meeting should have a leader (a
facilitator) to keep the conversation moving in a productive
direction, (2) to mediate any conflict that does occur, and (3)
to ensure than other principles are followed
Principle 4. Face-to-face communication is best.
But it usually works better when some other representation
of the relevant information is present.
For example, a participant may create a drawing or a
“strawman” document that serves as a focus for discussion
Principle 5. Take notes and document decisions.
Things have a way of falling into the cracks. Someone
participating in the communication should serve as a
“recorder” and write down all important points and
decisions
Principle 6. Strive for collaboration
Each small collaboration serves to build trust among team
members and creates a common goal for the team
Principle 7. Stay focused
Modularize your discussion. The more people involved in any
communication, the more likely that discussion will bounce
from one topic to the next.
The facilitator should keep the conversation modular, leaving
one topic only after it has been resolved
Principle 8. If something is unclear, draw a picture. Verbal
communication goes only so far.
A sketch or drawing can often provide clarity when words fail
to do the job.
Principle 9. (a) Once you agree to something, move on.
(b) If you can’t agree to something, move on.
(c) If a feature or function is unclear and cannot be clarified at
the moment, move on.
Communication, like any software engineering activity, takes
time. Rather than iterating endlessly,
“moving on” is sometimes the best way to achieve
communication agility.
Principle 10. Negotiation is not a contest or a game.
It works best when both parties win.
If the team has collaborated well, all parties have a
common goal.
Still,negotiation will demand compromise from all
parties.
 Planning Principles
Principle 1. Understand the scope of the project..
Scope provides the software team with a destination.
Principle 2. Involve stakeholders in the planning activity.
Stakeholders define priorities and establish project
constraints. software engineers must often negotiate
order of delivery , time lines, and other project-related
issues.
Principle 3. Recognize that planning is iterative.
iterative, incremental process models dictate replanning
after the delivery of each software increment based on
feedback received from users.
Principle 4. Estimate based on what you know.
The intent of estimation is to provide an indication
of effort, cost, and task duration, based on the
team’s current understanding of the work to be
done.
Principle 5. Consider risk as you define the plan.
If you have identified risks that have high impact
and high probability, contingency planning is
necessary.
Principle 6. Be realistic.
People don’t work 100 percent of every day.
Change will occur.
Even the best software engineers make mistakes.
These and other realities should be considered as a project plan is
established.
Principle 7. Adjust granularity as you define the plan. Granularity
refers to the level of detail that is introduced as a project plan is
developed.
A “high-granularity” plan provides significant work task detail that is
planned over relatively short time increments (so that tracking and
control occur frequently).
A “low-granularity” plan provides broader work tasks that are
planned over longer time periods.
Principle 10. Track the plan frequently and make
adjustments as required.
Software projects fall behind schedule one day at a
time.
It makes sense to track progress on a daily basis,
looking for problem areas when slippage is
encountered, the plan is adjusted accordingly .
 Modelling Principles
on agile modeling, Scott Ambler and Ron Jeffries
define a set of modeling principles that for those who
use the agile process model
appropriate for all software engineers who perform
modeling actions and tasks.
Principle 1. The primary goal of the software team is to
build software, not create models.
Principle 2. Travel light—don’t create more models
than you need.
Principle 3. Strive to produce the simplest model that will
describe the problem or the software.
Principle 4. Build models in a way that makes them amenable
to change.
Principle 5. Be able to state an explicit purpose for each model
that is created.
Principle 6. Adapt the models you develop to the system at
hand.
Principle 7. Try to build useful models, but forget about
building perfect models.
Principle 9. If your instincts tell you a model isn’t right
even though it seems okay on paper, you probably have
reason to be concerned.
Principle 10. Get feedback as soon as you can
Requirements modeling principles.
Principle 1. The information domain of a problem must be represented
and understood.
Principle 2. The functions that the software performs must be defined.
Principle 3. The behavior of the software (as a consequence of external
events) must be represented.
Principle 4. The models that depict information, function,
and behavior must be partitioned in a manner that uncovers
detail in a layered (or hierarchical) fashion.
Principle 5. The analysis task should move from essential
information toward implementation detail.