0% found this document useful (0 votes)
8 views

Lecture 8

Uploaded by

stylishkhan760
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
0% found this document useful (0 votes)
8 views

Lecture 8

Uploaded by

stylishkhan760
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/ 15

Principles that Guide

Practice
Ahsan Riaz
Department of Computer
Science
CUI, Abbottabad Campus
Slide Set to accompany
Software Engineering: A Practitioner’s Approach, 7/e
by Roger S. Pressman

Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman

For non-profit educational use only

May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A
Practitioner's Approach, 7/e. Any other reproduction or use is prohibited without the express written permission of the
author.

These slides All


are designed
copyright MUST appearSoftware
to accompany
information Engineering:
if these slides are posted on aAwebsite for student use.
Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by
Roger Pressman.

1
Quick Recap
 Agile Process Models
 Extreme Programming (XP)
 Scrum
 Human Factor in Agile

2
Today Agenda
 Software Engineering Practices
 A Big Picture – Understanding Principles
 Principles that guide Process
 Principles that guide Practice
 Principles that guide Framework Activities

3
Software Engineering Practice
 People who create computer software practice the discipline
that is software engineering. But what is software
engineering “practice”?

 In a generic sense, practice is a collection of concepts,


principles, methods, and tools that a software engineer calls
upon on a daily basis.

4
Software Engineering Practice
 Practice transforms a haphazard unfocused approach into
something that is more organized, more effective, and more
likely to achieve success.

 Practice allows managers to manage software projects and


software engineers to build computer programs.

 Practice populates a software process model with the


necessary technical and management how-to’s to get the job
done.

5
Principles – a Big Picture
 Principles that Guide Process
 Principles that Guide Practice
 Principles that Guide Framework Activities
 Communication Principles
 Planning Principles
 Modeling Principles
• Requirement/Analysis Modeling Principles
• Design Modeling Principles
 Construction Principles
• Coding Principles (Preparation, Programming, validation)
• Testing Principles
 Deployment Principles
6
Principles that Guide Process
-I
 Principle #1. Be agile. Whether the process model you choose is prescriptive or agile,
the basic tenets of agile development should govern your approach.

 Principle #2. Focus on quality at every step. The exit condition for every process
activity, action, and task should focus on the quality of the work product that has
been produced.

 Principle #3. Be ready to adapt. Process is not a religious experience. When


necessary, adapt your approach to constraints imposed by the problem, the people,
and the project itself.

 Principle #4. Build an effective team. Software engineering process and practice are
important, but the bottom line is people. Build a self-organizing team that has mutual
trust and respect.

7
Principles that Guide Process
- II
 Principle #5. Establish mechanisms for communication and coordination. Projects fail
because important information falls into the cracks and/or stakeholders fail to
coordinate their efforts to create a successful end product.

 Principle #6. Manage change. The approach may be either formal or informal, but
mechanisms must be established to manage the way changes are requested, assessed,
approved and implemented.

 Principle #7. Assess risk. Lots of things can go wrong as software is being developed.
It’s essential that you establish contingency plans.

 Principle #8. Create work products that provide value for others. Create only those
work products that provide value for other process activities, actions or tasks.

8
Principles that Guide
Practice
 Principle #1. Divide and conquer. Stated in a more technical manner, analysis
and design should always emphasize separation of concerns (SoC).

 Principle #2. Understand the use of abstraction. At it core, an abstraction is a


simplification of some complex element of a system used

 Principle #3. Strive for consistency. A familiar context makes software


easier to use.

 Principle #4. Focus on the transfer of information. Pay special attention to


the analysis, design, construction, and testing of interfaces.

9
Principles that Guide
Practice
 Principle #5. Build software that exhibits effective modularity. Separation of
concerns (Principle #1) establishes a philosophy for software. Modularity
provides a mechanism for realizing the philosophy.

 Principle #6. Look for patterns. Brad Appleton [App00] suggests that: “The
goal of patterns within the software community is to create a body of
literature to help software developers resolve recurring problems
encountered throughout all of software development.

 Principle #7. When possible, represent the problem and its solution from a
number of different perspectives.

 Principle #8. Remember that someone will maintain the software.

10
Communication Principles
 Principle #1. Listen. Try to focus on the speaker’s words, rather than
formulating your response to those words.

 Principle # 2. Prepare before you communicate. Spend the time to


understand the problem before you meet with others.

 Principle # 3. Someone should facilitate the activity. Every communication


meeting should have a leader (a facilitator) (1) to keep the conversation
moving in a productive direction; (2) to mediate any conflict that does occur,
and (3) to ensure that 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.

11
Communication Principles
 Principle # 5. Take notes and document decisions. Someone participating in the communication
should serve as a “recorder” and write down all important points and decisions.

 Principle # 6. Strive for collaboration. Collaboration and consensus occur when the collective
knowledge of members of the team is combined …
 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.
 Principle # 8. If something is unclear, draw a picture.
 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.
 Principle # 10. Negotiation is not a contest or a game. It works best when both parties win.

12
Planning Principles
 Principle #1. Understand the scope of the project. It’s impossible to use a
roadmap if you don’t know where you’re going. Scope provides the software
team with a destination.

 Principle #2. Involve the customer in the planning activity. The customer
defines priorities and establishes project constraints.

 Principle #3. Recognize that planning is iterative. A project plan is never


engraved in stone. As work begins, it very likely that things will change.

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

13
Planning Principles
 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.
 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.
 Principle #8. Define how you intend to ensure quality. The
plan should identify how the software team intends to ensure
quality.
 Principle #9. Describe how you intend to accommodate
change. Even the best planning can be obviated by
uncontrolled change.
 Principle #10. Track the plan frequently and make
adjustments as required. Software projects fall behind schedule
one day at a time.
14
Summary
 Software Engineering Practices
 A Big Picture – Understanding Principles
 Principles that guide
 Process
 Practice
 Framework Activities

15

You might also like