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
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
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
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
Negotiation is not a contest or game
Goals for Communication
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
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
Develop one page written statement of project scope
Review statement of scope with stakeholder and revise as needed
Collaborate with customer/end-users to define usage scenarios, input, outputs, software features and functions, customer business risks
Develop written descriptions of user scenarios, inputs, outputs, features, functions, and risks
Iterate with customer to define priorities for user scenarios, features, functions, and risks
Assign customer defined priorities to each user scenario, feature, and function
Review all information gathered with customers and other stakeholders
Prepare for planning activity
Planning Principles
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
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
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
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
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
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
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
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
If your instincts tell you there is something wrong with the model then you probably have a reason to be concerned
Get feedback as soon as you can
Coding Principles
Before writing any code be sure you:
Understand problem to solve
Understand basic design principles
Pick a programming language that meets the needs of the software to be built and the environment
Select a programming environment that contains the right tools
Create a set of unit tests to be applied once your code is completed
As you begin writing code be sure you:
Use structured programming practices
Select data structures that meet the needs of the design
Understand software architecture and create interfaces consistent with the architecture
Keep conditional logic as simple as possible
Create nested loops in a way that allows them to be testable
Select meaningful variable names consistent with local standards
Write code that is self-documenting
Use a visual layout for you code that aids understanding
After your complete your first coding pass be sure you:
Conduct a code walkthrough when appropriate
Perform unit tests and correct uncovered errors
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
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
Build the architectural infrastructure
Build a software component
Unit test the component
Integrate completed component into architectural infrastructure
Deployment Principles
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
