Software Engineering Guiding

Principles
Software Engineering
CONTENT
1. Objectives

2. Introduction

3. Process Guiding Principles

4. Practice Guiding Principles

5. Communication Principles

6. Planning Principles

7. Modeling Principles

8. Building Principles

9. Deployment Principles

10. Summary

11. Bibliography
 Software Engineering Guiding Principles | 3

Objectives The fundamental At the practice level,

Practice
principles establish a the fundamental

Process
• To define the fundamental principles that guide
the process of software engineering. philosophical principles define a
• To specify the principles that guide the process foundation that set of values and
and practice within software engineering. guides the software rules that serve as a
• To summarize the principles of communication, team as it guide when analyzing
planning, modeling, building and deployment.
performs structural and a problem, designing

Introduction shadow activities, as a solution, implementing

well as navigates the process and testing it, as well as
The practice of software engineering comprises a low and produces a when, in the end, the
comprehensive set of principles, concepts, methods,
set of software engineering software is delivered to
and tools that must be considered when planning and
designing software [1]. (Figure 1) These elements are work products. the user community.
constantly and recurrently consulted by the software
engineer.

The software process provides a guide for everyone

involved in the creation of a computer-based system or
product that will help to successfully reach the destination. Table 1. For the realization of this document, we have used, to a large
extent, text extracted from the book Software Engineering. A Practical
The practice provides the details that will be needed to Approach by Pressman [1].
navigate the road. It indicates where bridges, closed roads
and forks are located. It helps to understand the concepts
and principles that must be understood and followed in
order to arrive safely and quickly. It teaches how to drive,
Process Guiding
where to slow down and where to accelerate. In the context Principles
of software engineering, practice is what you do day in and
day out as the software evolves from idea to reality. The following fundamental principles apply to the
structure of the process, regardless of whether the model
There are three elements of practice that apply, in a is linear or iterative, prescriptive or agile.
general way, no matter which process model is chosen.
These elements are principles, concepts, and methods. • Principle 1. Be agile. Whether the process model
Software engineering practice gives the software process chosen is prescriptive or agile, it is the basic
model the technical and managerial knowledge to get the principles of agile development that should govern
job done. Practice transforms an uncertain process into the approach. Every aspect of the work that is done
something more organized, more efficient, and much more should emphasize economy of action: in keeping
likely to achieve the end result in a satisfactory manner. the technical approach as simple as possible,
making the work products that are generated as
As fundamental principles, it could be said that software concise as possible, and making decisions locally,
engineering practice is guided by a set of fundamental wherever possible.
principles that help in the application of the software • Principle 2. In every step, focus on quality. The
process and in the execution of effective software output condition for every activity, action and task in
engineering methods (Table 1) [1]. the process should focus on the quality of the work
product that has been generated.
• Principle 3. Be ready to adapt. The process is not
a religious experience; there is no room for dogma.
It will be necessary to adapt the approach to the
constraints imposed by the problem, the people and
the project itself.
Methods Concepts • Principle 4. Build an effective team. The process
and practice of software engineering are important,
Practice of but the focus is on people. It is necessary to form
SE a team with its own organization in which there is
mutual trust and respect.
Tools Principles

Figure 1. Practice of SE
 Software Engineering Guiding Principles | 4

• Principle 5. Establish mechanisms for • Principle 2. Understand the use of abstraction.

communication and coordination. Projects fail At its core, an abstraction is a simplification of
because important information falls through the some complex element of a system used to
cracks or because participants do not coordinate communicate meaning in a single sentence.
their efforts to create a successful end product. Many different levels of abstraction are used in
These are aspects of management that must be software engineering practice. The goal of an
addressed. abstraction is to eliminate the need to communicate
• Principle 6. Manage change. The approach may details, but sometimes the problematic effects
be formal or informal, but mechanisms must be precipitated by these details "leak out" everywhere.
in place to manage the way in which changes are Without an understanding of the details, the cause
requested, evaluated, approved, and implemented. of a problem cannot be easily diagnosed [2].
• Principle 7. Assess risk. There are many things • Principle 3. Seek consistency. Whether creating a
that can go wrong when developing software. It is requirements model, developing a software design,
essential to establish contingency plans. generating source code, or building test cases,
the consistency principle suggests that a familiar
• Principle 8. Create work products that add value for
context makes software easier to use. As an
others. It is necessary to generate only those work
example, consider the design of a user interface for
products that add value for other activities, actions
a webapp. Consistent placement of menu options,
or tasks in the process. Any work product that is
use of a consistent color scheme, and consistent
generated as part of the software engineering
use of recognizable icons help make the interface
practice will be passed on to someone else. The list
ergonomically very good.
of required functions and features will be given to
the person(s) who will develop a design, the design • Principle 4. Focus on information transfer. Software
will be passed on to those who generate code, is all about information transfer: from a database to
and so on. It is necessary to ensure that the work an end user, from a legacy system to a webapp, from
product imparts the necessary information without an end user to a graphical user interface (GUI), from
ambiguity or omissions. an operating system to an application, from one
software component to another, the list is almost

Practice Guiding endless. In all cases, information flows through

an interface and, as a consequence, there are
Principles possibilities for errors, omissions or ambiguities.
This principle implies that special attention must
The practice of software engineering has a single overall be paid to the analysis, design, construction and
goal: to deliver on time high quality operational software testing of interfaces.
containing functions and features that meet the needs of • Principle 5. Build software that has effective
all stakeholders [1]. modularity. Entity separation establishes a
On the basis of achieving that goal, a set of principles philosophy for software. Modularity provides a
should be chosen to guide the work of software mechanism for carrying out that philosophy. Any
engineers. These principles have merit regardless of the complex system can be divided into modules
analysis and design methods applied, and regardless (components), but good software engineering
of the construction techniques. At this point, there is no practice demands more. Modularity must be
regard for the programming languages or automated effective.
tools employed, or the verification or validation approach • Principle 6. Look for patterns. Brad Appleton [3]
chosen. suggests the following:
The goal of patterns within the software
The following fundamental principles are vital to the community is to create a body of literature to
practice of software engineering: help software developers resolve recurring
• Principle 1. “Divide and conquer”. Put more problems encountered throughout all of
technically, analysis and design should always software development. Patterns help create
emphasize the separation of entities (SoE). A large a shared language for communicating insight
problem is easier to solve if it is divided into a set and experience about these problems and their
of elements (or entities). Ideally, each entity should solutions.
deliver distinct functionality that can be developed
and, in certain cases, validated, independently of
other entities.
 Software Engineering Guiding Principles | 5

• Principle 7. When possible, represent the • Principle 5. Take notes and document decisions.
problem and its solution from several different Things find a way to fall through the cracks.
perspectives. When a problem and its solution are Someone involved in communication should serve
studied from several different perspectives, it is as "secretary" and write down all important issues
more likely to have a better view and to detect errors and decisions. .
and omissions. • Principle 6. Pursue collaboration. Collaboration and
• Principle 8. Keep in mind that someone will consensus occur when the collective knowledge
maintain the software. The software will be of team members is used to describe functions
corrected in the long run, when its defects are or features of the product or system. Each small
discovered, when it adapts to changes in its collaboration serves to build trust among team
environment, and when it is improved when members and creates a common goal for the group.
the participants ask for more capabilities. • Principle 7. Stay focused; make modules out of
These maintenance activities are easier if the discussion. The more people involved in any
a sound software engineering practice is communication, the more likely the conversation
applied throughout the software process. will jump from one topic to another.
These principles are not all that is needed to produce
• Principle 8. If something is unclear, draw a picture.
high quality software, but they lay the foundation
Verbal communication has its limits. Often, an
for all of the software engineering methods studied
outline or drawing provides clarity when words are
and discussed in this document.
not enough to do the job.

Communication Principles • Principle 9. a) Once something is agreed upon,

move forward. b) If it is not possible to agree
on something, move forward. c) If a feature or
The first step is to achieve good communication with
function is unclear or cannot be clarified at the
the customer. This must be done before the customer's
time, move forward. Communication, like any
requirements are analyzed and modeled or specified.
software engineering activity, takes time.
A customer has a problem that appears to be addressable • Principle 10. Negotiation is not a contest or a
by a computer-based solution. The customer's request game. It works best when both parties win. There
for help is answered. Communication has begun. But it are many circumstances in which you and other
is often the case that the path from communication to participants must negotiate functions and features,
understanding is riddled with holes. priorities and delivery dates. If the team has
collaborated well, all parties will have a common
Effective communication is among the most difficult goal. Even so, negotiation will demand commitment
activities that must be faced. The communication from all parties.
principles outlined below are applied to communication
with the customer.

• Principle 1. Listen. Try to focus on the speaker's

words rather than formulating your response to
those words. If something is not clear, ask questions
to clarify it, but avoid constant interruptions.
• Principle 2. Before communicating, prepare. It is
necessary to spend some time understanding the
problem before meeting with others. If necessary,
some research could be done to understand the
business vocabulary.
• Principle 3. Someone must facilitate the activity.
Every communication meeting should have a leader
(facilitator) to keep the conversation moving in a
positive direction, mediate any conflicts that occur,
and ensure that other principles are followed.
• Principle 4. Face-to-face communication is
best. It generally works best when some other
representation of the relevant information is
present. For example, a participant may generate
a "draft" drawing or document that serves as the
focus of the discussion. .
 Software Engineering Guiding Principles | 6

Planning Principles • Principle 8. Define how quality reassurance is

addressed. The plan should identify how the
The planning activity includes a set of management software team seeks to assure quality. If technical
practices and techniques that enable the software team reviews are performed, they should be scheduled. If
to define a roadmap as it moves toward its strategic goal pair programming is to be used during the build, it
and tactical objectives [1]. should be explicitly defined in the plan.
• Principle 9. Describe how change is intended to be
It is impossible to predict exactly how a software project managed. Even the best planning can be nullified by
will unfold. There is no easy way to determine what uncontrolled change. The manner in which changes
technical problems will be encountered, what important are to be received as the software engineering work
information will remain hidden until the project is well progresses should be identified.
underway, what misunderstandings there will be, or what
• Principle 10. Monitor the plan frequently and
aspects of the business will change. Nevertheless, a
make adjustments as required. Software projects
good software team should plan with this approach.
fall behind schedule. Therefore, it makes sense
Planning should be taken sparingly enough to give useful to evaluate progress on a daily basis to look for
guidance to the team, no more, no less. Regardless of the problem areas and situations where scheduled
rigor with which planning is done, the following principles activities do not match actual progress. When
always apply: deviations are detected, the plan should be adjusted
accordingly.
• Principle 1. Understand the scope of the project.
It is impossible to use the map if you don't know
where you are going. The scope gives the software
Modeling Principles
team a destination. The fundamental objective of creating models is to gain
• Principle 2. Involve software stakeholders in this a better understanding of the software to be designed. A
planning activity. The stakeholders define the software model must be able to represent the information
priorities and set the constraints of the project. To that the software transforms, the architecture and
include these realities, software engineers often functions that enable this to happen, the features that
must negotiate the delivery schedule, deadlines, users want, and the behavior of the system as the
and other issues related to the project. transformation takes place.
• Principle 3. Acknowledge that planning is iterative. Models must meet these objectives at different levels
By the time the work starts, things will most likely of abstraction, first with the illustration of the software
have changed. Consequently, the plan will need to from the customer's point of view, and then with its
be adjusted to include those changes. In addition, representation at a more technical level.
incremental iterative process models dictate that
planning should be repeated after the delivery In software engineering work, two kinds of models are
of each software increment based on feedback created: requirements and design models [1].
received from users.
• Principle 4. Estimate based on what is known. The Requirements models, also known as analysis models,
objective of estimation is to obtain an index of the represent customer requirements by illustrating the
effort, cost, and duration of tasks based on the software in three different domains: information,
team's understanding of the work to be performed. functional and behavioral. Design models represent
If the information is vague or unreliable, then the characteristics of the software that help practitioners
estimates will also be unreliable. to develop it effectively: architecture, user interface, and
component-level detail.
• Principle 5. When defining the plan, account for
risk. If risks have been identified that would have
a large effect and are very likely to occur, then
contingency plans need to be developed.
• Principle 6. Be realistic. People do not work 100%
every day. In any human communication there is
noise. Omissions and ambiguity are a fact of life.
• Principle 7. Adjust granularity when defining
the plan. Granularity refers to the level of detail
adopted when developing a plan. A plan with "high
granularity" provides significant detail in the tasks
for the work being planned, in increments over a
relatively short period of time (so monitoring and
control happens frequently).
 Software Engineering Guiding Principles | 7

The set of modeling principles are defined in [4] and are • Principle 9. If a model is interpreted to be incorrect,
intended for all those who use the agile process model, even though it looks good on paper, there is reason
but are appropriate for all software engineers who to be concerned. If something says that a design
perform modeling actions and tasks: model is destined to fail (even if this cannot be
explicitly demonstrated), there is reason to spend
• Principle 1. The software team's main goal is to more time studying it or developing a different one.
build software, not to create models. Agility means
• Principle 10. Get feedback as soon as possible.
delivering software to the customer as quickly
Every model should be reviewed by team members.
as possible. Models that contribute to this are
The purpose of these reviews is to obtain feedback
beneficial, but those that slow the process or give
to be used to correct modeling errors, change
little insight should be avoided.
misinterpretations, and add inadvertently omitted
• Principle 2. Travel light, do not create more models features or functions.
than necessary. Any model that is created should
be updated if changes occur. More importantly,
any new model requires time that would otherwise Modeling Principles Requirements.
be spent on construction (coding and testing).
Therefore, it is necessary to create only those Each analysis method has a unique point of view.
models that make it easier and faster to build the However, they are all related by certain operational
software. principles:
• Principle 3. Try to produce the simplest model • Principle 1. The information domain of a
that describes the problem or the software. Do not problem must be represented and understood.
overbuild software. By keeping the models simple, The information domain includes data flowing into
the resulting software will also be simple. The the system (end users, other systems or external
result is that you will have software that is easy to devices), data flowing out of the system (through
integrate, easy to test and easy to maintain. the user interface, network interfaces, reports,
• Principle 4. Build models that are susceptible to graphics and other media) and data stores that
change. Assume that models will change, but be collect and organize persistent data objects (e.g.,
careful that this assumption does not make things those that are retained permanently).
sloppy. • Principle 2. The functions to be performed by the
• Principle 5. Be able to state an explicit purpose software should be defined. Software functions
for each model you create. Every time you create a provide a direct benefit to end users and also
model, you need to ask yourself why you are doing provide internal support for features that are visible
it. If you do not find a solid reason for the existence to end users. Some functions transform the data
of the model, it is better not to waste time on it. flowing into the system.
• Principle 6. Adapt the models being developed to • Principle 3. The behavior of the software (as
the system in question. Model notation or rules a consequence of external events) must be
may need to be adapted to the application. represented. The behavior of computer software
• Principle 7. Try to build useful models, but forget is determined by its interaction with the external
about building perfect models. When a software environment.
engineer builds requirements and design models, • Principle 4. Models representing information,
a point is reached where progress diminishes. That function, and behavior should be partitioned to
is, the effort required to completely finish the model reveal details in a layered (or hierarchical) fashion.
and make it internally consistent ceases to benefit Requirements modeling is the first step in solving
from having such properties. a software engineering problem. It provides a
• Principle 8. Do not be dogmatic about model better understanding of the problem and provides
syntax. If you are successful in communicating a basis for the solution (design). This concept is
content, the representation is secondary. Although called partitioning or entity separation, and is a key
each member of the software team should try to strategy in requirements modeling.
use a consistent notation during modeling, the most • Principle 5. The analysis work should progress from
important feature of the model is to communicate the essential information to the implementation in
information that enables the next engineering task detail. El modelado de requerimientos comienza con
to be performed. If a model succeeds in doing this,
incorrect syntax is forgivable.
 Software Engineering Guiding Principles | 8

la descripción del problema desde la perspectiva information to the professionals who will generate
del usuario final. the code, to those who will test the software, and
to others who will maintain it in the future. If the
design is difficult to understand, it will not serve as
Principles of Design Modeling an effective means of communication.
• Principle 9. The design should be developed
The design model that is created for the software gives
iteratively. The designer should strive for
several different views of the system.
simplicity in each iteration. As with almost all
• Principle 1. The design must be traceable to the creative activities, design occurs iteratively. The
requirements model. The requirements model first iterations serve to improve the design and
describes the information domain of the problem, correct errors, but subsequent iterations should
the functions visible to the user, the behavior of seek to make the design as simple as possible.
the system, and a set of requirements classes that External quality factors are those properties of the
group the business objects with the methods that software that are easily observable by users. Internal
serve them. quality factors are of importance to software engineers:
• Principle 2. Always take into account the they lead to a high quality design from a technical point
architecture of the system to be built. The software of view. To obtain internal quality factors, the designer
architecture is the skeleton of the system to be built. must understand the basic concepts of design [1].
• Principle 3. The design of the data is as important
as the design of the processing functions. The data
design is an essential element of the architecture
design.
• Principle 4. Interfaces (both internal and external)
must be designed with care. La manera en la
que los datos fluyen entre los componentes de
un sistema tiene mucho que ver con la eficiencia
del procesamiento, la propagación del error
y la simplicidad del diseño. Una interfaz bien
diseñada hace que la integración sea más fácil
y ayuda a quien la somete a prueba a validar las
funciones componentes.
• Principle 5. The user interface design should
be tailored to the needs of the end user.
However, it should always emphasize ease of use.
The user interface is the visible manifestation of
the software. No matter how sophisticated its
internal functions are, no matter how inclusive its
data structures are, no matter how well designed its
architecture is, poor interface design often leads to
the perception that the software is "bad".
• Principle 6. Design at the component
level must have functional independence.
Functional independence is a measure of the
"single-mindedness" of a software component. The
functionality delivered by a component must be
cohesive, that is, it must focus on one and only one
function or subfunction.
• Principle 7. Components must be loosely coupled
with each other and with the external environment.
Coupling is achieved in many ways: with a
component interface, with messaging, through
global data, among others. As the level of coupling
increases, the probability of error propagation
also increases and the overall ease of software
maintenance decreases. Therefore, component
coupling should be kept as low as reasonable.
• Principle 8. Design representations
(models) should be easily understood.
The purpose of the design is to communicate
 Software Engineering Guiding Principles | 9

Construction Principles The following principles and concepts are applicable to

coding and testing:
The build activity includes a set of coding and testing tasks • Coding principles. The principles that guide
that leads to a working software ready to be delivered to coding work relate closely to programming style,
the customer or end user. languages, and methods. However, a number of
In modern software engineering work, coding can be as fundamental principles can be stated:
follows: Principles of preparation: before writing a single line of
code, it is necessary to make sure of the following:
1. The direct creation of programming language in
source code (e.g., Java). • There is an understanding of the problem to be
2. The automatic generation of source code that uses solved.
an intermediate representation resembling the • There is an understanding of the basic design
design of the component to be built. principles and concepts.
3. The automatic generation of executable code that • The programming language chosen must meet
uses a "fourth generation programming language" the needs of the software to be developed and the
(e.g., Visual C++). environment in which it will operate.
• The programming environment selected must
Testing directs its initial attention to the component offer tools that make the work easier.
and is often referred to as unit testing. Other levels of
• A set of unit tests must be created, and they are to
testing include integration testing (performed while the
be applied once the component to be coded has
system is under construction), validation testing, which
been completed.
evaluates whether the requirements have been satisfied
for the entire system (or software increment), and
acceptance testing, which is performed by the customer
in an effort to use all required features and functions [1].
 Software Engineering Guiding Principles | 10

Programming principles: when you start writing code, it • Principle 2. Testing should be planned long before
is necessary to make sure of the following: actual testing begins. Test planning begins as soon
as the requirements model is completed. The
• Algorithms are restricted by use of structured detailed definition of test cases starts as soon as
programming. the design model has been completed. As a result,
• The use of pair programming has been taken into all tests can be planned and designed before any
consideration. code is generated.
• Data structures that meet the needs of the design • Principle 3. The Pareto principle applies to software
should be selected. testing. In this context, the Pareto principle implies
• The software architecture should be understood that 80% of all bugs not detected during testing
and interfaces that are congruent with it should be are related to 20% of all program components.
created. Of course, the problem is to isolate the suspect
components and test them thoroughly.
• Conditional logic is kept as simple as possible.
• Principle 4. Testing should start "small" and move
• Nested loops in a form that can be easily tested are
towards "big". The first tests planned and executed
created.
usually focus on individual components. As testing
• Meaningful variable names are selected and other progresses, the focus shifts to an attempt to find
local coding standards are followed. bugs in integrated groups of components and,
• Code that documents itself is written. ultimately, in the entire system.
• A visual image that assists understanding is created • Principle 5. Exhaustive testing is not possible.
(e.g., indented and blank lines). Even for a program of moderate size, the number
of path permutations is too large. For this reason, it
Validation principles: once the first coding attempt has is impossible to run all path combinations during a
been completed, it is necessary to ensure the following: test. However, it is possible to adequately cover the
• Code walkthrough is performed where appropriate. program logic and ensure that all conditions at the
component level have been tested.
• Unit tests are conducted and any errors that are
detected are corrected.
• Code is redesigned.

Testing principles: some rules that serve as test

objectives [5]:

• Testing is the process that executes a program in

order to find an error.
• A good test case is one that has a high probability
of finding a previously undetected error.
• A successful test is one that discovers a previously
undetected error.

The objective is to design tests that systematically detect

different kinds of bugs and to do so with the minimum
time and effort. If the tests are performed successfully
(in accordance with the objectives already mentioned),
bugs in the software will be discovered. As a side benefit,
testing demonstrates that software functions appear to
work according to specifications, and that behavioral and
performance requirements are apparently met [1]. Some
principles for testing are as follows:

• Principle 1. All testing should be traceable to

customer requirements. The goal of software
testing is to discover bugs. Therefore, the most
severe defects, from the customer's point of view,
are those that cause the program to fail to meet the
requirements.
 Software Engineering Guiding Principles | 11

Deployment Principles Summary

As has been mentioned previously, the nature of modern The practice of software engineering includes principles,
software process models is evolutionary or incremental. concepts, methods and tools that are applied by software
Deployment occurs not once, but several times, as the engineers throughout the development process. Every
software progresses toward completion. Each delivery software engineering project is different. However, there
cycle makes available to customers and end users an is a set of general principles that apply to the process as
increment of operational software that provides usable a whole and to every structural activity, no matter what
functions and features [1]. the project or product is.

Each feedback cycle gives the software team important There is a set of fundamental principles that aid in the
guidance that results in modifications to the functions, application of a meaningful software process and in the
features, and approach taken for the next increment. The execution of effective software engineering methods. At
delivery of a software increment represents an important the process level, the fundamental principles establish a
benchmark for any software project. When the team philosophical foundation that guides the software team
prepares to deliver an increment, certain key principles as it moves through the software process. At the practice
should be followed: level, the fundamental principles establish a set of values
and rules that serve as a guide when analyzing a problem
• Principle 1. Customer expectations must be design and solution, implementing it, testing it, and
managed. Too often, the customer expects ultimately deploying the software to the user community.
more than the team has promised to deliver and
disappointment comes immediately. This results in Communication principles focus primarily on deducing
unproductive feedback and ruins team morale. and clarifying the customer's needs, as well as the need
• Principle 2. The complete package to be delivered to reduce noise and improve the exchange during the
must be assembled and tested. All installation conversation between the developer and the customer.
scripts and other operational features should be Collaboration between both parties is imperative in order
fully executed on as many different computer to achieve the best communication. The principles of
configurations as possible (e.g., hardware, planning are based on the establishment of guidelines
operating systems, peripheral equipment, network to elaborate the best mapping of the process towards
configurations, etc.). a system or finished product. The plan can be designed
for only one software increment or for the whole project.
• Principle 3. Before delivering software, a support
Regardless, it should define what will be done, who will
regime should be established. An end user expects
do it, and when the work will be completed.
an accurate response and information when a
question or problem arises. The principles that guide modeling are designed to
• Principle 4. End users should be provided with include both analysis and design, in turn, describe
appropriate learning materials. The software team increasingly detailed representations of the software.
delivers more than the software itself. Appropriate Creating models is intended to affirm an understanding
training materials should be developed (if required). of the work to be done and to provide technical guidance
Troubleshooting guidelines should be provided to those who will implement the software. Modeling
and, where necessary, "what is different about this principles underpin the methods and notation used to
software increment" should be published. create representations of the software.
• Principle 5. Defective software should be corrected
The coding cycle comes into operation at the construction
first, and then released. When the increment is
stage, as does testing, where source code is generated
released, end users should be invited to comment
for certain components that are tested. The coding
on features and functions, ease of use, reliability
principles define the general actions that should take
and any other characteristics.
place before the code is written, while it is being written,
and after it is completed. Although there are many
principles for testing, only one predominates: testing is
the process of running a program in order to find a bug.
 Software Engineering Guiding Principles | 12

Throughout the software development process, the

customer receives updates or increments of the
application. It is at this point that the principles of
deployment are included and include delivery, support
and feedback. The key principles for delivery include
managing customer expectations and providing
adequate support information about the software.
Support demands advance preparation. Feedback allows
the customer to suggest changes that have business
value and provide the developer with information for the
next iterative software engineering cycle.

Bibliography
[1] R. S. Pressman, “Ingeniería del software. Un enfoque
práctico”. Séptima Edición ed., Mc Graw Hill.
[2] J. Spolsky, “The law of leaky abstraction”, 2002. [En
línea]. Disponible en: https://www.joelonsoftware.
com/2002/11/11/the-law-of-leaky-abstractions/
[Último acceso: 21 04 2022].
[3] B. Appleton, “Patterns and software: essential
concepts and terminology”, 2000. [En línea].
Disponible en: https://www.cmcrossroads.com/
users/brad-appleton [Último acceso: 21 04 2022].
[4] S. W. Amber, “Agile Modeling”, John Wiley, 2002.
[5] G. Myers, “The art of software testing”, Wiley, 1979.