CHAPTER 5 – SOFTWARE ENGINEERING PRACTICE
2005 McGraw-Hill Higher Education
http://highered.mcgraw-hill.com/sites/0072853182/student_view0/chapter5/chapter_summary.html
Overview
This chapter describes professional practice as the concepts, principles, methods, and tools used by
software engineers and managers to plan and develop software. Software engineers must be
concerned both with the technical details of doing things and the things that are needed to build
high-quality computer software. Software process provides the project stakeholders with a roadmap
to build quality products. Professional practice provides software engineers with the detail needed to
travel the road. Software practice encompasses the technical activities needed to produce the work
products defined by the software process model chosen for a project.
Software Engineering Process Framework Activities





Communication (developer stakeholder collaboration)
Planning
Modeling (requirements and design)
Construction (code generation and testing)
Deployment (customer provides feedback on delivered products)
Software Engineering Process Umbrella Activities








Software project tracking and control
Risk Management
Software quality assurance
Formal technical reviews
Measurement
Software configuration management
Reusability management
Work product preparation and production
Essence of Practice




Understand the problem (communication and analysis)
Plan a solution (software design)
Carry out the plan (code generation)
Examine the result for accuracy (testing and quality assurance)
Understand the Problem




Who are the stakeholders?
What functions and features are required to solve the problem?
Is it possible to create smaller problems that are easier to understand?
Can a graphic analysis model be created?
Plan the Solution




Have you seen similar problems before?
Has a similar problem been solved?
Can readily solvable subproblems be defined?
Can a design model be created?
Carry Out the Plan
Page 1 of 5


Does solution conform to the plan?
Is each solution component provably correct?
Examine the Result


Is it possible to test each component part of the solution?
Does the solution produce results that conform to the data, functions, and features
required?
Software Practice Core Principles
1.
2.
3.
4.
5.
6.
7.
Software exists to provide value to its users
Keep it simple stupid (KISS)
Clear vision is essential to the success of any software project
Always specify, design, and implement knowing that someone else will have to understand
what you have done to carry out his or her tasks
Be open to future changes, don't code yourself into a corner
Planning ahead for reuse reduces the cost and increases the value of both the reusable
components and the systems that require them
Placing clear complete thought before any action almost always produces better results
Principles of Effective Communication
1.
2.
3.
4.
5.
6.
7.
8.
9.
Listen
Prepare before you communicate
Have a facilitator for any communication meeting
Face-to-face communication is best
Take notes and document decisions
Strive for collaboration
Stay focused and modularize your discussion
Draw a picture if something is unclear
Move on once you agree, move on when you can't agree, move on if something unclear
can't be clarified at the moment
10. Negotiation is not a contest or game
Goals for Communication
1.
2.
3.
4.
5.
Identify the customer and other stakeholders
Establish an effective mode of communication between developers and stakeholders
Develop usage scenarios
Identify constraints
Establish priorities
Generic Task Set for Communication
1.
2.
Identify primary customer and other stakeholders
Meet with customer to define business needs and values, end-user characteristics and
needs, required outputs, and business constraints
3. Develop one page written statement of project scope
4. Review statement of scope with stakeholder and revise as needed
5. Collaborate with customer/end-users to define usage scenarios, input, outputs, software
features and functions, customer business risks
6. Develop written descriptions of user scenarios, inputs, outputs, features, functions, and
risks
7. Iterate with customer to define priorities for user scenarios, features, functions, and risks
8. Assign customer defined priorities to each user scenario, feature, and function
9. Review all information gathered with customers and other stakeholders
10. Prepare for planning activity
Page 2 of 5
Planning Principles
1.
2.
3.
4.
5.
6.
7.
8.
9.
Understand scope of project
Involve customer in planning activities
Recognize that planning is iterative
Make estimates based on what you know
Consider risk as you define the plan
Adjust the granularity as you define the plan
Define how you will measure quality
Describe how you will accommodate change
Track the plan frequently and make adjustments as needed
Boehm's W5HH Principle
1.
2.
3.
4.
5.
6.
7.
Why is the system being developed?
What will be done?
When will it be accomplished?
Who is responsible for a function?
Where will they organizationally be located?
How will the job be done technically and managerially?
How much of each resource is needed?
Goals for Planning




Develop an overall project strategy
Identify the functionality to be delivered by each software increment
Develop a detailed plan for the current iteration
Track progress of a regular basis
Generic Task Set for Planning
1.
2.
3.
4.
5.
6.
7.
8.
9.
Re-evaluate project scope
Assess risks
Develop/refine user scenarios
Extract functions and features from scenarios
Define technical functions and features needed for software infrastructure
Group functions and features according to customer priorities
Create a low granularity project plan
Create high granularity plan for current iteration
Track progress regularly
Analysis Modeling Principles
1.
2.
3.
4.
5.
The information domain for the problem must be represented and understood
Functions performed by the software must be defined
Software behavior must be represented as consequences of external events
Models depicting the information, function, and behavior must be partitioned in manner that
uncovers detail in a hierarchical fashion
The analysis task should move from essential information toward implementation detail
Generic Goals for Modeling







Page 3 of 5
Review requirements and constraints
Expand and refine user scenarios
Model information domain
Define analysis classes using information objects as a guide
Represent responsibilities and collaborations of each analysis class
Group related classes into packages
Model functional domain


Model behavioral domain
Analyze and model the user interface
Design Modeling Principles
1.
2.
3.
4.
5.
6.
7.
8.
9.
Design should be traceable to the analysis model
Always consider the architecture of the system to be built
Data design is as important as algorithm design
Internal and external interfaces must be designed with care
User interface design should be tuned to the needs of the end-user and must focus on use
of user
Component-level design should be functionally independent
Components should be loosely coupled to one another and to the external environment
Design models should be easy to understand
Design should be developed iteratively
Generic Task Set for Design
1.
2.
3.
4.
5.
6.
7.
Using the analysis model select and architectural style appropriate to the software
Partition analysis model into subsystems and allocate subsystems within the architecture
Examine the information domain model and design appropriate data structures for data
objects and their attributes
Create a set of design classes
Design User interface
Conduct component-level design
Develop deployment model
Agile Modeling Principles
1.
2.
3.
4.
5.
6.
7.
8.
Primary goal of the software team is to build software not create models
Don't create any more models than you have to
Strive to produce the simplest model that will describe the problem or software
Build models in a way that makes them amenable to change
Be able to state the explicit purpose for each model created
Adapt models to the system at hand
Try to build useful models, forget about trying to build perfect models
Don't be dogmatic about model syntax as long as the model communicates content
successfully
9. If your instincts tell you there is something wrong with the model then you probably have a
reason to be concerned
10. Get feedback as soon as you can
Coding Principles


Page 4 of 5
Before writing any code be sure you:
o Understand problem to solve
o Understand basic design principles
o Pick a programming language that meets the needs of the software to be built and
the environment
o Select a programming environment that contains the right tools
o Create a set of unit tests to be applied once your code is completed
As you begin writing code be sure you:
o Use structured programming practices
o Select data structures that meet the needs of the design
o Understand software architecture and create interfaces consistent with the
architecture
o Keep conditional logic as simple as possible
o Create nested loops in a way that allows them to be testable
o Select meaningful variable names consistent with local standards
o Write code that is self-documenting
o Use a visual layout for you code that aids understanding

After your complete your first coding pass be sure you:
o Conduct a code walkthrough when appropriate
o Perform unit tests and correct uncovered errors
o Refactor the code
Testing Goals



Testing is the process of executing a program with the intent of finding an error
A good test is one that has a high probability of finding an undiscovered error
A successful test is one that uncovers an undiscovered error
Testing Principles
1.
2.
3.
4.
5.
All tests should be traceable to customer requirements. Note: White-box tests are traceable
only indirectly.
Tests should be planned long before testing begins
Testing Pareto Principle (80% of errors are found in 20% of code)
Testing should begin "in the small" and progress toward testing "in the large"
Exhaustive testing is not possible
Generic Task Set for Construction
1.
2.
3.
4.
Build the architectural infrastructure
Build a software component
Unit test the component
Integrate completed component into architectural infrastructure
Deployment Principles
1.
2.
3.
4.
5.
Customer software expectations must be managed
Complete delivery package should be assembled and tested
Support regime must be established before software is delivered
Appropriate instructional materials must be supplied to end-users
Buggy software should be fixed before it is delivered
Generic Task Set for Deployment
1.
2.
3.
4.
5.
6.
Page 5 of 5
Create delivery media
Establish the human support person(s)
Establish user feedback mechanisms
Disseminate delivery media to all users
Conduct on-going support functions
Collect user feedback