1

Software Engineering Practice

2
What is “Practice”?
 Practice is a broad array of concepts, principles, methods,
and tools that you must consider as software is planned and
developed.
 It represents the details—the technical considerations and
how to’s—that are below the surface of the software
process—the things that you’ll need to actually build high-
quality computer software.
 Equips managers to manage software projects and software
engineers to build computer programs
 Transforms a haphazard unfocused approach into something
that is more organized, more effective, and more likely to
achieve success
3
The Essence of Practice
 George Polya, in a book “How to Solve it” written in
1945 (!), describes the essence of software engineering
practice …
 Understand the problem (communication and analysis).
 Plan a solution (modeling and software design).
 Carry out the plan (code generation).
 Examine the result for accuracy (testing and quality
assurance).
 At its core, good practice is common-sense problem
solving

4
The Essence of Practice
 Understand the problem:
 Who has a stake in the solution to the problem? i.e. Who are Stakeholders?
 What are the unknowns (data, function, behavior)?
 Can the problem be compartmentalized?
 Can the problem be represented graphically?
 Plan a solution:
 Have you seen similar problems like this before? Patterns?
 Has a similar problem been solved and is the solution reusable?
 Can subproblems be defined and are solutions available for the subproblems?
 Carry out the plan:
 Does the solution conform to the plan? Is the source code traceable back to the
design?
 Is each component of the solution correct? Has the design and code been reviewed?
 Examine the result for accuracy:
 Is it possible to test each component of the solution?
 Does the solution produce results that conform to the data, function, and behavior
that are required?
5
Core Software Engineering Principles
1) Remember the reason that the software exists
 The software should provide value to its users and satisfy the requirements
2) KIS—keep it simple!
 All design and implementation should be as simple as possible
3) Maintain the product and project “vision”
 A clear vision is essential to the project’s success
4) What you produce, others will consume
 Always specify, design, and implement knowing that someone else will
later have to understand and modify what you did
5) Be open to the future
 Never design yourself into a corner; build software that can be easily
changed and adapted
6) Plan ahead for reuse
 Reuse of software reduces the long-term cost and increases the value of the
program and the reusable components
7) Think!
 Placing clear, complete thought before action will almost always produce
better results
6
Software Engineering Practices
 Consider the generic process framework
 Communication
 Planning
 Modeling
 Construction
 Deployment
 Here, we’ll identify
 Underlying principles
 How to initiate the practice
 An abbreviated task set
7
Communication Practices
 Principles
1. Listen
 Listen to the speaker and concentrate on what is being said
 Ask for clarification if something is unclear, but avoid constant interruptions
2. Prepare before you communicate
 Prepare before you meet by researching and understanding the problem
3. Someone should facilitate the activity
 Someone should facilitate the meeting and have an agenda
4. Face-to-face communication is best
 Face-to-face communication is best, but also have a document or
presentation to focus the discussion
5. Take notes and document decisions
 Someone participating in the communication should serve as recorder and
write down all important points and decisions. 8
Communication Practices(contd)
6. Strive for Collaboration
 Collaboration and consensus occur when the collective knowledge of
members of the team is combined to describe the product or system
functions
7. Stay focused, modularize your discussion.
 Stay focused on a topic; modularize your discussion
8. If something is unclear, draw a picture
 Drawing or sketch often provide more clarity
9. Move on …
 Move on to the next topic a) after you agree to something, b) if you cannot
agree to something, or c) if a feature or function is unclear and cannot be
clarified at the moment
10. Negotiation is not a contest or game. It works best when
both parties win.
 Negotiation demands compromise from all parties
9
Communication Practices
 Initiation
 The parties should be physically close to one another
 Make sure communication is interactive
 Create solid team “ecosystems”
 Use the right team structure
 An abbreviated task set
 Identify who it is you need to speak with
 Define the best mechanism for communication
 Establish overall goals and objectives and define the scope
 Get more detailed
 Have stakeholders define scenarios for usage
 Extract major functions/features
 Review the results with all stakeholders
10
Planning Practices
 Principles
1. Understand the scope of the project
 Scope provides the software team with a destination
2. Involve the customer (and other stakeholders) in the
planning activity
 Customer defines priorities and establishes project constraints. So Software
engineers must often interact with them on various project related issues
3. Recognize that planning is iterative
 As most process models are iterative and incremental, replanning often
becomes necessary
4. Estimate based on what you know
 The intent of estimation is to provide an indication of effort, cost and task
duration, based on team’s current understanding of the work to be done.
5. Consider risk as you define the plan
 Risk assessment and contingency planning is necessary
11
Planning Practices
6. Be realistic
 Even the best software engineers make mistakes. So realities should be
considered as project plan is established
7. Adjust granularity as you define the plan
 Granularity refers to the level of detail that is introduced as a project plan is
developed. Fine granularity- detailed, Coarse granularity-Broad
8. Define how you intend to ensure quality
 Plan should incorporate FTR’s and other such tasks
9. Describe how you intend to accommodate change
 How changes can be accommodated? Immediately or in next increment
10. Track the plan frequently and make adjustments as required
 Track progress on a daily basis. If slippage occurs, adjust plan accordingly

12
Planning Practices
 Initiation
 Barry Boehm’s W5HH Principle
 Why is the system begin developed?
 What will be done?
 When will it be accomplished?
 Who is responsible?
 Where are they located (organizationally)?
 How will the job be done technically and managerially?
 How much of each resource is needed?

13
Planning Practices
 An abbreviated task set
 Re-assess project scope
 Assess risks
 Evaluate functions/features
 Consider infrastructure functions/features
 Create a coarse granularity plan
 Number of software increments
 Overall schedule
 Delivery dates for increments
 Create fine granularity plan for first increment
 Track progress
14
Modeling Practices
 We create models to gain a better understanding of the
actual entity to be built
 Analysis models represent the customer requirements by
depicting the software in three different domains: the
information domain, the functional domain, and the
behavioral domain.
 Design models represent characteristics of the software
that help practitioners to construct it effectively: the
architecture, the user interface, and component-level
detail.
15
Analysis Modeling Practices
 Analysis modeling principles
1. The information domain of the problem must be represented and understood
 Information domain encompasses the data that flows in and out of a system
2. The functions that the software performs must be defined
 Functions can be described at various levels of abstraction
3. The behavior of the software (as a consequence of external events) must be
represented
 Behavior of computer software is driven by its interaction with the external environment.
4. The models that depict information, function, and behavior must be
partitioned in a manner that uncovers detail in a layered (or hierarchical)
fashion
 Analysis modeling is the first step in SE problem solving. Use partitioning, wherever
necessary
5. The analysis task should move from essential information toward
implementation detail
 First essence of the problem should be developed
 Elements of the analysis model
 Data model
 Flow model
 Class model
 Behavior model
16
Design Modeling Practices
 Principles
1. Design should be traceable to the analysis model
 Relevant classes, packages must be defined along with their methods
2. Always consider architecture of the system to be built.
 Design should start with architectural considerations
3. Design of data is as important as design of processing functions
4. Interfaces (both external and internal) must be designed with care
5. User interface design should be tuned to the needs of the end-user
6. Component-level design should be functionally independent (high
cohesion)
7. Components should be loosely coupled to one another and to the
external environment
8. Design representations (models) should be easily understandable
9. The design should be developed iteratively; with each iteration, the
designer should strive for greater simplicity
Elements of the design model
 Data design
 Architectural design
 Component design
 Interface design
 External quality factors: those properties that can be readily observed
 Internal quality factors: those properties that lead to a high-quality design from a technical perspective
17
Construction Practices
 Preparation principles: Before you write one line of code,
be sure you:
1. Understand of the problem you’re trying to solve (see
communication and modeling)
2. Understand basic design principles and concepts.
3. Pick a programming language that meets the needs of the
software to be built and the environment in which it will
operate.
4. Select a programming environment that provides tools
that will make your work easier.
5. Create a set of unit tests that will be applied once the
component you code is completed.
18
Construction Practices
 Coding principles: As you begin writing code, be sure you:
1. Constrain your algorithms by following structured programming
[BOH00] practice.
2. Select data structures that will meet the needs of the design.
3. Understand the software architecture and create interfaces that are
consistent with it.
4. Keep conditional logic as simple as possible.
5. Create nested loops in a way that makes them easily testable.
6. Select meaningful variable names and follow other local coding
standards.
7. Write code that is self-documenting.
8. Create a visual layout (e.g., indentation and blank lines) that aids
understanding.
19
Construction Practices
 Validation Principles: After you’ve completed your first
coding pass, be sure you:
1. Conduct a code walkthrough when appropriate.
2. Perform unit tests and correct errors you’ve uncovered.
3. Refactor the code.

20
Construction Practices
 Testing Principles
1. All tests should be traceable to customer requirements
2. Tests should be planned before unit testing begins
3. The Pareto Principle applies to software testing
 80% of the uncovered errors are in 20% of the code
4. Testing begins “in the small” and progress toward testing
“in the large”
5. Exhaustive testing is not possible
1) Testing is a process of executing a program with the intent of finding an
error
2) A good test case is one that has a high probability of finding an as-yet
undiscovered error
3) A successful test is one that uncovers an as-yet undiscovered error
21
Deployment Practices
 Principles
1) Customer expectations for the software must be managed
• Be careful not to promise too much or to mislead the user
2) A complete delivery package should be assembled and tested
3) A support regime must be established before the software is
delivered
4) Appropriate instructional materials must be provided to end
users
5) Buggy software should be fixed first, delivered later

22