BCS501, SEPM

Chapter 2: Principles that guide practice

Software Engineering Knowledge

Steve McConnell's editorial highlights the distinction between technology-specific knowledge and
enduring software engineering principles.

1. Technology-Specific Knowledge:

o Software practitioners often focus on knowledge of specific

technologies (e.g., Java, Perl, C++, Linux).

o This knowledge is necessary for performing specific programming tasks.

o Technology-related knowledge tends to have a short half-life (about 3 years),

meaning it can become obsolete quickly.

2. Enduring Software Engineering Principles:

o McConnell argues that there is another type of knowledge, which he calls

"software engineering principles."

o These principles do not have a short half-life and are likely to be useful
throughout a programmer's career.

o They form a stable core of knowledge essential for developing complex

systems.

3. Stable Core of Knowledge:

o By the year 2000, McConnell estimated that about 75 percent of the knowledge
needed to develop a complex system resided within this stable core.

o This core consists of fundamental principles that guide software engineers

in their work.

Mrs. Pooja R Rao, Asst Prof, RNSIT (CSE-DS) Page 1

 BCS501, SEPM

4. Application and Evaluation:

o The core principles provide a foundation from which software engineering

models, methods, and tools can be applied and evaluated.

In essence, McConnell emphasizes the importance of focusing not only on transient technological
skills but also on enduring software engineering principles that form the stable foundation of the
discipline.

Core principles

The core principles of software engineering are essential for both the process and practice levels,
providing a foundation and guiding values for effective development.

Principles That Guide Process

1. Be Agile:

o Emphasize simplicity and economy of action.

o Keep work products concise and make local decisions when possible.

2. Focus on Quality at Every Step:

o Ensure every activity and task produces high-quality work products.

3. Be Ready to Adapt:

o Adapt approaches based on constraints from the problem, people, and project.
4. Build an Effective Team:

o Focus on building a self-organizing team with mutual trust and respect.

5. Establish Mechanisms for Communication and Coordination:

o Address management issues to ensure critical information is shared and

coordinated effectively.

Mrs. Pooja R Rao, Asst Prof, RNSIT (CSE-DS) Page 2

 BCS501, SEPM

6. Manage Change:

o Establish formal or informal mechanisms to manage change requests,

assessments, approvals, and implementations.
7. Assess Risk:

o Identify potential issues and establish contingency plans.

8. Create Work Products That Provide Value for Others:

o Produce only those work products that are necessary and valuable for subsequent
process activities.

Principles That Guide Practice

1. Divide and Conquer:

o Emphasize separation of concerns to simplify solving large problems.

2. Understand the Use of Abstraction:

o Use abstractions to simplify complex elements, starting with high- level

models and refining to lower levels.
3. Strive for Consistency:

o Maintain consistency in requirements models, designs, source codes, and test

cases for ease of use and understanding.
4. Focus on the Transfer of Information:

o Pay attention to the analysis, design, construction, and testing of interfaces

to ensure clear and accurate information flow.
5. Build Software That Exhibits Effective Modularity:

o Ensure modules are cohesive in function, have low coupling, and are
interconnected simply.
6. Look for Patterns:

o Utilize patterns to resolve recurring problems and create a shared language

Mrs. Pooja R Rao, Asst Prof, RNSIT (CSE-DS) Page 3

 BCS501, SEPM

for solutions and good architectural practices.

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

o Examine problems and solutions from multiple viewpoints (e.g., data- oriented,
function-oriented, behavioral) for greater insight and error detection.
8. Remember That Someone Will Maintain the Software:

o Apply solid software engineering practices to facilitate future

maintenance activities such as corrections, adaptations, and
enhancements.

These principles establish a robust foundation for every software engineering method and guide the
development of high-quality, operational software that meets stakeholders' needs.

Principles that guide each framework activity

Communication Principles
Effective communication is crucial in software projects, particularly when gathering customer
requirements. These principles apply to all forms of communication within a project but are
especially important for customer interactions:

1. Listen: Focus on the speaker’s words and ask for clarification without constant
interruptions.
2. Prepare Before You Communicate: Understand the problem and prepare an agenda if
you’re conducting a meeting.
3. Someone should facilitate the activity: Ensure meetings have a leader to keep
discussions productive and mediate conflicts.

4. Face-to-Face Communication Is Best: Use additional representations, like drawings or

documents, to aid discussions.
5. Take Notes and Document Decisions: Record all important points and decisions to
avoid losing information.

Mrs. Pooja R Rao, Asst Prof, RNSIT (CSE-DS) Page 4

 BCS501, SEPM

6. Strive for Collaboration: Build trust and common goals through

collaboration and consensus among team members.
7. Stay Focused; Modularize Your Discussion: Keep discussions focused on one topic at
a time to avoid bouncing between topics.
8. If Something Is Unclear, Draw a Picture: Use sketches or drawings to clarify verbal
communication.
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: If you agree, move on; if you can’t agree, move on; if something
is unclear, move on.
10. Negotiation Is Not a Contest or a game. It works best when both parties win: Aim for
win-win negotiations, compromising as needed to achieve common goals.

Planning Principles
Effective planning provides guidance to the software team and helps manage the project's
progression:

1. Understand the Scope of the Project: Know the project’s destination to use a road map
effectively.
2. Involve Stakeholders in the Planning Activity: Engage stakeholders to define
priorities and establish constraints.
3. Recognize That Planning Is Iterative: Adjust the plan as work progresses and new
information emerges.
4. Estimate Based on What You Know: Provide estimates based on the current
understanding of the work.

5. Consider Risk as You Define the Plan: Adjust the project plan to
accommodate high-impact, high-probability risks.
6. Be Realistic: Account for human factors, communication noise, and the likelihood
of changes and mistakes.
7. Adjust Granularity as You Define the Plan: Plan in detail for the short term and

Mrs. Pooja R Rao, Asst Prof, RNSIT (CSE-DS) Page 5

 BCS501, SEPM

broadly for the long term, adjusting as needed.

8. Define How You Intend to Ensure Quality: Identify and schedule quality assurance
activities like technical reviews and pair programming.
9. Describe How You Intend to Accommodate Change: Define how changes will be
requested, assessed, and implemented.
10. Track the Plan Frequently and Make Adjustments as Required: Monitor progress daily
and adjust the plan to address slippages.

Modeling Principles
Models help in understanding and building the software. There are two types of models:
requirements models (analysis models) and design models. Agile modeling principles, although
intended for agile processes, apply to all software engineering:
1. The primary goal of the software team is to build software, not create models: Create
models that facilitate getting software to the customer quickly.
2. Travel light – don’t create more models than you need: Create only necessary
models to avoid wasting time on upkeep and construction delays.
3. Strive to produce the simplest model that will describe the problem or the software:
By keeping models simple, the resultant software will also be simple. Simple models are easier for
members of the software team to understand and critique, resulting in an ongoing form of feedback
that optimizes the end result.
4. Build models in a way that makes them amendable to change: Keep models simple to
ensure the software is simple, easier to integrate, test, and maintain.
5. Be able to state an explicit purpose for each model that is created: Create models
that can be easily updated as requirements change.

6. Adapt the models you develop to the system at hand: Justify the creation of each
model; if not justified, don’t create it.
7. Try to build useful models, but forget about building perfect models: Tailor model
notation or rules to the specific application.
8. Don’t become dogmatic about the syntax of the model. If it communicates content
successfully, representation is secondary: Aim for useful models rather than perfect

Mrs. Pooja R Rao, Asst Prof, RNSIT (CSE-DS) Page 6

 BCS501, SEPM

ones; avoid diminishing returns.

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: Focus on
successful communication of content rather than strict adherence to syntax.
10. Get Feedback as soon as you can: Review models with the team to correct mistakes,
address misinterpretations, and add missing features.

These principles collectively guide software engineering efforts, ensuring that processes and
practices are effective, efficient, and adaptable to changing requirements and circumstances.

Requirements Modeling Principles

Requirements modeling methods have evolved significantly, addressing various analysis

problems through unique modeling notations and heuristics. However, they share common
operational principles:

1. The information domain of a problem must be represented and understood

o Encompasses data flow into the system, data flow out, and data stores.

o Ensures a comprehensive understanding of the data involved.

2. The functions that the software performs must be defined

o Involves specifying functions that provide user-visible benefits and internal

support.
3. The behavior of the software must be represented

o Software behavior is driven by interactions with external

environments.
o Input from users, external systems, or networks triggers specific behaviors.
4. The models that depict information, function and behavior must be partitioned in a
manner that uncovers detail in a layered fashion

o Models depicting information, function, and behavior should be layered.

Mrs. Pooja R Rao, Asst Prof, RNSIT (CSE-DS) Page 7

 BCS501, SEPM

o This divide-and-conquer strategy simplifies complex problems into manageable

subproblems.
5. The analysis task should move from essential information toward implementation detail

o Starts with a user perspective, describing the problem without

implementation details.
o Gradually includes implementation specifics, considering user interaction
methods.

Design Modeling Principles

Design modeling translates requirements into detailed plans, providing multiple views of the
system. Key principles include:

1. Design should be traceable to the requirements model

o Design elements should directly correlate with requirements.

2. Always consider the architecture of the system to be built

o Focus on the overall system architecture before delving into

component details.

o Functions transform data, control processing, or interact with external elements.

3. Design of data is as important as design of processing functions

o Data structures should be well-designed to simplify program flow and component

design.
4. Interfaces must be designed with care

o Both internal and external interfaces must be designed for efficiency, error
reduction, and simplicity.
5. User interface design should be turned to the needs of the end user. However, in every
case, it should stress ease of use

o Should cater to user needs, prioritizing ease of use.

Mrs. Pooja R Rao, Asst Prof, RNSIT (CSE-DS) Page 8

 BCS501, SEPM

6. Component-level design should be functionally independent

o Components should be cohesive, focusing on a single function or

subfunction.
7. Components should be loosely coupled to one another and to the external environment

o Minimize interdependence to reduce error propagation and improve

maintainability.
8. Design representations should be easily understandable

o Design models should be clear and communicable.

9. The design should be developed iteratively. With each iteration, the designer should strive
for greater simplicity

o Design should evolve iteratively, aiming for simplicity with each iteration.

Construction Principles
The construction phase involves coding and testing tasks leading to operational software:

Coding Principles
1. Preparation Principles: Before you write one line of code, be sure you
o Understand the problem and design principles.

o Choose appropriate programming languages and environments.

o Create unit tests for components.

2. Programming Principles: As you begin writing code, be sure you

o Constrain your algorithms by following structured programming [Boh00] practice.

o Consider the use of pair programming.

o Select data structures that will meet the needs of the design.

o Understand the software architecture and create interfaces that are consistent with it.

o Keep conditional logic as simple as possible.

Mrs. Pooja R Rao, Asst Prof, RNSIT (CSE-DS) Page 9

 BCS501, SEPM

o Create nested loops in a way that makes them easily testable.

o Select meaningful variable names and follow other local coding standards

3. Validation Principles: After you’ve completed your first coding pass, be sure you

o Conduct code walkthroughs and unit tests.

o Refactor code as necessary.

Testing Principles
1. All tests should be traceable to customer requirements

o Tests should map directly to customer requirements.

2. Tests should be planned long before testing begins

o Plan tests early, ideally as soon as requirements and design models are solidified.
3. The Pareto principle applies to software testing

o Focus on the 20% of components likely to contain 80% of errors.

4. Testing should begin “in the small” and progress toward testing “in the large”

o Start with small components and progress to integrated system testing.

5. Exhaustive testing is not possible

o Focus on adequate coverage rather than exhaustive path testing.

Deployment Principles
Deployment involves delivery, support, and feedback:

1. Customer expectations for the software must be managed

o Communicate clearly to avoid overpromising and under-delivering.

2. A complete delivery package should be assembled and tested

o Include all necessary executable software, support files, and

Mrs. Pooja R Rao, Asst Prof, RNSIT (CSE-DS) Page 10
 BCS501, SEPM

documents.
3. A support regime must be established before the software is delivered

o Ensure responsive and accurate support for users.

4. Appropriate instructional materials must be provided to end users

o Include training aids, troubleshooting guidelines, and updates on new increments.

5. Buggy software should be fixed first, delivered later

Mrs. Pooja R Rao, Asst Prof, RNSIT (CSE-DS) Page 11