SOFTWARE ENGINEERING PRACTICE

SWE1204
Aaron Atuhe
July 2022
 introduction
• People who create computer software
practice the art of craft or discipline that is
software engineering. But what it software
engineering “practice”?
• In a generic sense, practice is a collection of
concepts, principles, methods, and tools that
a software engineer calls upon on a daily
basis.
• Practice allows managers to manage software

projects and software engineers to build computer

programs.

• Practice populates a software process model with

the necessary technical and management how-to

get the job done.

• Practice transforms a haphazard unfocused
approach into something that is more
organized, more effective and more likely to
achieve success.
• Some writers argue for one of these terms to
the exclusion of the others. In reality, software
engineering is all three.
 What is it?
• Practice is a broad array of concepts,
principles, methods, and tools that you must
consider as software planned and developed.

• It represents the details-the technical

considerations and how to—that are below
the surface of the software process
 Who does it?
• The practice of software engineering is applied
by software engineers and their managers.
 Why is it important?

• The software process provides everyone

involved in the creation of a computer-based
system or product with a road map for getting
to a destination successfully.
• Practice provides you with the detail you’ll
need to drive along the road.
• It tells you where the bridges, the roadblocks,

and the forks are located.

• It helps you understand the concepts and

principles that must be understood and

followed to drive safely and rapidly.

• It instructs you on how to drive, where to slow
down, and where to speed up.
• In the context of software engineering, practice is
what you do day in and day out as software
evolves from an idea to a reality.
 What are the steps?
• Three elements of practice apply regardless of
the process models that is chosen. They are:
• concepts,
• principles, and
• methods.
• A fourth element of practice—tools—
supports the application of methods.
 What is the work product?

• Practice encompasses the technical activities

that produce all work products that are

defined by the software process model that

has been chosen.

 The essence Practice

• In a classic book, How to Solve It, written before

modern computers existed, gorge Polya outlined the
essence of problem solving, and consequently, the
essence of software engineering practice:

1. Understand the problem (communication and

analysis).
2. Plan a solution (modeling and software design).
3. Carry out the plan (code generation).
4. Examine the result for accuracy (testing and
quality assurance).
 Understand the problem:
Who has a stake in the solution to the problem? That is, who are
the stakeholders?

• What are the unknowns? What data, functions, features, and

behaviour are required to properly solve the problem?

• Can the problem be compartmentalized? Is it possible to

represent smaller problems that may be easier to understand?

Can the problem be represented graphically? Can an analysis

model be created?
 Plan the solution:
• Have you seen similar problems before? Are there
patterns that are recognizable in a potential solution?
Is there existing software that implements the data,
functions, features, and behaviour that are required?

• Has a similar problem been solved? If so, are solutions

readily apparent for the sub-problems?

• Can you represent a solution in a manner that leads to

effective implementation? Can a design model be created?
 Carry out the plan

• Does the solution confirm to the plan? IS

source code traceable to the design model?

• Is each component part of the solution

probably correct? Have the design and code
been received, or better, has correctness proof
been applied to the algorithm?
 Examine the result:

• Is it possible to test each component part of the

solution? Has a reasonable testing strategy been
implemented?

• Does the solution produce results that confirm to

the data? Functions, features and behaviour that are
required?
Has the software been validated against all
stakeholder requirements?
 COMMUNICATION PRACTICES
• Before customer requirements can be
analysed, modelled, or specified they must be
gathered through a communication (also
called requirements elicitation) activity.
• A customer has a problem that may be
amenable to a computer- based solution.
• A developer responds to the customer’s
request for help. Communication has begun.
• Effective communication (among technical
peers, with the customer and other
stakeholders, and with project managers) is
among the most challenging activities that
confronts a software engineer.
 Generic task set for Communication
• 1. Identify primary customer and other stakeholders.

2. Meet with primary customer to address “context

free questions” that define.
• Business need and business values.
• End-users’ characteristics / needs.
• Required user- visible outputs.
• Business constraints.

3. Develop a one- page written statement of project

scope that is subject to revision
4. Review statement of scope with stakeholders and amend as
required.

5. Collaborate with customer/end- users to define:

• Resulting outputs and inputs.
• Important software features, functions, and behaviour.
• Customer-defined business risks.

6. Develop a brief written description (e.g., a set of lists) of

scenarios, output/ inputs, features/ functions and risks.

7. Iterate with customer- defined priorities to each user scenario,

feature, function, and behaviour.
8. Assign customer- defined priorities to each
user scenario, feature, function, and behaviour.

9. Review all information gathered during the

communication activity with the customer and
other stakeholder and armed as required.

10. Prepare for planning activity.

 PLANNING PRACTICES

• The communication activity helps a software team to

define its overall goals and objectives (subject, of
course, to change as time passes). However,
understanding these goals and objectives is not the
same as defining a plan for getting there.

• The planning activity encompasses a set of management

and technical practices that enable the software tam to
define a road map as it travels towards its strategic goal
and technical objectives.
• What to do? On many projects, over planning is
time consuming and fruitless (too many things
change), but under planning is a recipe for chaos.

• Like most things in life, planning should be

conducted in moderation, enough to provide
useful guidance for the team- no more, no less.
 Generic task set for Planning:
• 1.Re-evaluate project scope.
2. Assess risks.
3. Develop and/or refine user scenarios.
4. Extract functions and features from the scenarios.
5. Define technical functions and features that enable
software infrastructure.
6. Group functions and features (scenarios) by customer
priority.
7. Create a coarse granularity project plan.
• Define the number of projected software increments.
• Establish an overall project schedule.
• Establish projected delivery dates for each increment
• 8 Create a fine granularity plan for the current
iteration.
• Define work tasks for each functional feature.
• Estimate effort for each work task.
• Assign responsibility for each work task.
• Define work products to be produced.
• Identify quality assurance methods to be used.
• Describe methods for managing change.
9. Track progress regularly.
• Make adjustments as required.
 MODELING PRACTICE

• The models are created to gain better

understanding of actual entity to be built.
When the entity is a physical thing, we can
build a model that is identical in form of shape
but smaller in scale.
However, when the entity is software, our model
must take a different form.
• It must be capable of representing the information
that software transforms,
• the architecture and functions that enable the
transformation to occur,
• the features that user’s desire, and the behaviour
of the system as the transformation is taking place.
 Two classes of models are crated:
• Analysis models and design models.

• Analysis models represent the customer

requirements by depicting the software in
three different domains: the information
domain, the functional domain, and the
behavioural domain.
• Design models represent characteristics of the
software that help practitioners to construct it
effectively.
• The design model created for software
provides a variety of different views of system.
There is no shortage of methods for deriving
various elements of a software design.
 Data-driven methods

• Some methods are data-driven, allowing the

data structure to dictate the program
architecture and the resultant processing
component.
 Pattern driven methods

• Others are pattern-driven, using information

about the problem domain (the analysis model)
to develop architectural styles and processing
patterns- a set of design principles that can be
applied regardless of the method that is used.
 CONSTRUCTION PRACTICE

• The construction activity encompasses a set of

coding and testing task that lead operational
software that is ready for delivery to the
customer or end-user.
 In software engineering work, coding may
be
• 1. the direct creation of programming
language source code;
• 2 . the automatic generation of source code
using an intermediate design-like
representation of the component to be built;
• 3. the automatic generation of executable
code using a fourth generation programming
language.
 Deployment practise

The deployment activity encompasses three

actions delivery, support, and feedback.
Because modern software process models are
evolutionary in nature, deployment happens not
once, but a number of times as software moves
towards completion.
• Each delivery cycle provides the customer and
end-users with an operational software
increment that provides usable functions and
features.
• The delivery of a software increment
represents an important milestone for any
software project.
 Review Questions

• 1. Discuss software engineering practice and the

various elements involved therein.
• 2. Explain the seven core principles of software
engineering practice.
• 3. What is modelling practice? Discuss in detail the
various models
• 5. Explain the construction practice encompassing
coding and testing tasks.
• 6. Discuss the deployment activity in the software
field
• How does system engineering lead to effective
engineering?
• How is the analysis model created, and what are its
elements?
• What is design engineering, and what are the
underlying concepts that lead to good design?
• What concepts, models and methods are used to create
architectural, interface, and component level designs?

• What measures and metrics can be used to assess the

quality of analysis and design models, source code and
test cases?