Software

Engineering
Practice
2023
PTIK - UNS
 Ellen Ullman
I have no idea what time it is. There are no windows in this office and no
clock, only the blinking red LED display of a microwave, which flashes
12:00, 12:00, 12:00, 12:00.

Joel and I have been programming for days. We have a bug, a stubborn
demon of a bug. So the red pulse no-time feels right, like a read-out of
our brains, which have somehow synchronized themselves at the same
blink rate . . .

What are we working on? . . . The details escape me just now. We may
be helping poor sick people or tuning a set of low-level routines to verify
bits on a distributed database protocol—I don’t care. I should care; in
another part of my being—later, perhaps when we emerge from this
room full of computers—I will care very much why and for whom and
for what purpose I am writing software. But just now: no. I have passed
through a membrane where the real world and its uses no longer matter.
I am. . . .

a software engineer. . . .
Software Engineering Practice
 Consists of a collection of concepts, principles, methods, and tools that a
software engineer calls upon on a daily basis
 Equips managers to manage software projects and software engineers to build
computer programs
 Provides necessary technical and management how to’s in getting the job done
 Transforms a haphazard unfocused approach into something that is more
organized, more effective, and more likely to achieve success

3
 Seven Core Principles for Software Engineering
1) Remember the reason that the software exists
• The software should provide value to its users and satisfy the requirements

2) Keep it simple, stupid (KISS)

• All design and implementation should be as simple as possible

3) Maintain the vision of the project

• A clear vision is essential to the project’s success

4) Others will consume what you produce

• 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 software reuse

• Reuse of software reduces the long-term cost and increases the value of the program and the reusable
components
7) Think, then act
• Placing clear, complete thought before action will almost always produce better results
Although these general principles are important, they are characterized at such a high level of abstraction that
they are sometimes difficult to translate into day-to-day software engineering practice.
 Core Principle: Process Guide
 Principle 1. Be agile. Whether the process model you choose is prescriptive or agile, the
basic tenets of agile development should govern your approach. Every aspect of the work
you do should emphasize economy of action—keep your technical approach as simple as
possible!
 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, an dogma has no place
in it. When necessary, adapt your approach to constraints imposed by the problem, the
people, and the project itself.
 Core Principle: Process Guide
 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.
 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. These are management issues and they must be addressed.
 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.
 Core Principle: Process Guide
 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. Every work
product that is produced as part of software engineering practice will be passed on to
someone else. A list of required functions and features will be passed along to the person
(people) who will develop a design, the design will be passed along to those who generate
code, and so on. Be sure that the work product imparts the necessary information without
ambiguity.
 Core Principle: Practice Guide
 Principle 1. Divide and conquer. Stated in a more technical manner, analysis and design
should always emphasize separation of concerns (SoC). A large problem is easier to solve if
it is subdivided into a collection of elements (or concerns). Ideally, each concern delivers
distinct functionality that can be developed, and in some cases validated, independently of
other concerns.
 Core Principle: Practice Guide
 Principle 2. Understand the use of abstraction. At its core, an abstraction is a simplification of some complex
element of a system used to communicate meaning in a single phrase. In software engineering practice, you use
many different levels of abstraction, each imparting or implying meaning that must be communicated. In
analysis and design work, a software team normally begins with models that represent high levels of
abstraction and slowly refines those models into lower levels of abstraction
 Core Principle: Practice Guide
 Principle 3. Strive for consistency. Whether it’s creating a requirements model, developing a software
design, generating source code, or creating test cases, the principle of consistency suggests that a familiar
context makes software easier to use.

 As an example, consider the design of a user interface for a WebApp. Consistent placement of menu
options, the use of a consistent color scheme, and the consistent use of recognizable icons all help to
make the interface ergonomically sound.
 Core Principle: Practice Guide
 Principle 4. Focus on the transfer of information. Software is about information
transfer—from a database to an end user, from a legacy system to a WebApp, from an
end user into a graphic user interface (GUI), from an operating system to an application,
from one software component to another—the list is almost endless. In every case,
information flows across an interface, and as a consequence, there are opportunities for
error, or omission, or ambiguity. The implication of this principle is that you must pay
special attention to the analysis, design, construction, and testing of interfaces.
 Core Principle: Practice Guide
 Principle 5. Build software that exhibits effective
modularity. Modularity provides a mechanism for
realizing the philosophy. Any complex system can be
divided into modules (components), but good software
engineering practice demands more. Modularity must
be effective. That is, each module should focus
exclusively on one well-constrained aspect of the
system—it should be cohesive in its function and/or
constrained in the content it represents. Additionally,
modules should be interconnected in a relatively simple
manner—each module should exhibit low coupling to
other modules, to data sources, and to other
environmental aspects.
Core Principle: Practice Guide
 Principle 6. Look for patterns. Brad Appleton 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. Patterns help create a shared language for
communicating insight and experience about these problems and their
solutions. Formally codifying these solutions and their relationships lets us
successfully capture the body of knowledge which defines our understanding of
good architectures that meet the needs of their users.
Core Principle: Practice Guide
 Principle 7. When possible, represent the problem and its solution from a
number of different perspectives. When a problem and its solution are
examined from a number of different perspectives, it is more likely that greater
insight will be achieved and that errors and omissions will be uncovered. For
example, a requirements model can be represented using a data oriented
viewpoint, a function-oriented viewpoint, or a behavioral viewpoint
Core Principle: Practice Guide
 Principle 8. Remember that someone
will maintain the software. Over the
long term, software will be corrected
as defects are uncovered, adapted as its
environment changes, and enhanced as
stakeholders request more capabilities.
These maintenance activities can be
facilitated if solid software engineering
practice is applied throughout the
software process.
The Essence of Problem Solving

1) Understand the problem (communication and analysis)

• Who has a stake in the solution to the problem?
• What are the unknowns (data, function, behavior)?
• Can the problem be compartmentalized?
• Can the problem be represented graphically?

2) Plan a solution (planning, modeling and software design)

• Have you seen similar problems like this before?
• Has a similar problem been solved and is the solution reusable?
• Can subproblems be defined and are solutions available for the subproblems?
 The Essence of Problem Solving
3) Carry out the plan (construction; code generation)
• 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?

4) Examine the results for accuracy (testing and quality assurance)

• 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?

This leads to principle that guide framework activity

 Communication Practices
(Requirements Elicitation)
Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Tracking Modeling
Analysis
Design Construction
Code
Test Deployment
Delivery
Support
Feedback
 Communication Principles
1) Listen to the speaker and concentrate on what is being said
2) Prepare before you meet by researching and understanding the problem
3) Someone should facility the meeting and have an agenda
4) Face-to-face communication is best, but also have a document or presentation to focus the
discussion
5) Take notes and document decisions
6) Strive for collaboration and consensus
7) Stay focused on a topic; modularize your discussion
8) If something is unclear, draw a picture
9) 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 a game; it works best when both parties win
 Planning Practices
(Defining a Road Map)
Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Tracking Modeling
Analysis
Design Construction
Code
Test Deployment
Delivery
Support
Feedback
 Planning Principles
1) Understand the scope of the project
2) Involve the customer in the planning activity
3) Recognize that planning is iterative; things will change
4) Estimate based only on what you know
5) Consider risk as you define the plan
6) Be realistic on how much can be done each day by each person and how well
7) Adjust granularity as you define the plan
8) Define how you intend to ensure quality
9) Describe how you intend to accommodate change
10)Track the plan frequently and make adjustments as required
Barry Boehm’s W5H2 Principle
 Why is the system being developed?
 What will be done?
 When will it be accomplished?
 Who is responsible for each function?
 Where are they organizationally located?
 How will the job be done technically and managerially?
 How much of each resource is needed?

The answers to these questions lead to a definition of key

project characteristics and the resultant project plan
 Modeling Practices
(Analysis and Design)
Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Tracking Modeling
Analysis
Design Construction
Code
Test Deployment
Delivery
Support
Feedback
Analysis Modeling Principles
1) The information domain of a problem (the data that flows in and out of a
system) must be represented and understood
2) The functions that the software performs must be defined
3) The behavior of the software (as a consequence of external events) must be
represented
4) The models that depict information, function, and behavior must be
partitioned in a manner that uncovers detail in a layered (or hierarchical)
fashion
5) The analysis task should move from essential information toward
implementation detail
 Design Modeling Principles
1) The design should be traceable to the analysis model
2) Always consider the software architecture of the system to be built
3) Design of data is as important as design of processing functions
4) Interfaces (both internal and external) must be designed with care
5) User interface design should be tuned to the needs of the end-user and should stress ease of use
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

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
 Construction Practices
Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Tracking Modeling
Analysis
Design Construction
Code
Test Deployment
Delivery
Support
Feedback
 Coding Principles
(Preparation before coding)

1) Understand the problem you are trying to solve

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
28
 Coding Principles
(As you begin coding)
1) Constrain your algorithms by following structured programming practices
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 code understanding

29
 Coding Principles
(After completing the first round of code)

1) Conduct a code walkthrough

2) Perform unit tests (black-box and white-box) and correct
errors you have uncovered
3) Refactor the code

30
 Testing Principles
1) All tests should be traceable to the software requirements
2) Tests should be planned long before testing begins
3) The Pareto principle applies to software testing
• 80% of the uncovered errors are in 20% of the code
4) Testing should begin “in the small” and progress toward testing
“in the large”
• Unit testing --> integration testing --> validation testing --> system testing
5) Exhaustive testing is not possible

31
 Test Objectives

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

32
 Deployment Practices
Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Tracking Modeling
Analysis
Design Construction
Code
Test Deployment
Delivery
Support
Feedback
 Deployment 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

 34
End of Chapter 3