Software

Engineering

By Miss Nida E Rub

Course Introduction
Course Outline
• Nature of Software
• Overview of Software Engineering
• Professional software development
• Software engineering practice
• Software process structure
• Software process models
• Agile software Development
• Agile process models
• Agile development techniques
• Requirements engineering process
• Functional and non-functional requirements
• Context models
Course Outline
• Interaction models
• Structural models
• behavioral models
• model driven engineering
• Architectural design
• Design and implementation
• UML diagrams
• Design patterns
• Software testing and quality assurance
• Software evolution
• Project management and project planning
• configuration management
• Software Process improvement
Chapter # 1

SOFTWARE AND
SOFTWARE ENGINEERING
1.1 THE NATURE OF SOFTWARE
1.1.1 What is Software?
Software is a set of instructions, data or programs used to
operate computers and execute specific tasks.
• The product that software professionals build and then
support over the long-term.
Software encompasses:
• (1) Instructions (computer programs) that when executed
provide desired features, function, and performance
• (2) Data structures that enable the programs to adequately
store and manipulate information
• (3) Documentation that describes the operation and use of
the programs.
1.1.2 Legacy Software
Why must it change?
• Software must be adapted to meet the needs
of new computing environments or
technology.
• Software must be enhanced to implement new
business requirements.
• Software must be extended to make it
interoperable with other more modern
systems or databases.
• Software must be re-architected to make it
viable within a network environment.
1.1.3 Software Applications
• System software
• Application software
• Engineering/scientific software
• Embedded software
• Product-line software
• Webapps (web applications)
• AI software
1.2 THE UNIQUE NATURE OF
WEBAPPS
Home Task
Read and summarize
1.2 THE UNIQUE
NATURE OF WEBAPPS

Book pg # 10
1.3. SOFTWARE ENGINEERING
1.3 Software Engineering
• Software engineering is a detailed study of engineering to the
design, development and maintenance of software. (Google)
• The practical application of scientific knowledge to the design and
construction of computer programs and the associated
documentation required to develop, operate, and maintain them
[Boehm].
• The systematic approach to the development, operation,
maintenance, and retirement of software [IEEE].
• Multi-person construction of multi-version software [Parnas].
• “Software from womb to tomb.”
1.3 Software Engineering
• Some realities:
• a concerted effort should be made to understand the problem
before a software solution is developed
• design becomes a pivotal activity
• software should exhibit high quality
• software should be maintainable
• The seminal definition:
• Software engineering is the establishment and use of sound
engineering principles in order to obtain economically software
that is reliable and works efficiently on real machines. [Bauer].
1.3 Software Engineering
• A Layered Technology Software engineering is a
fully layered technology, to
develop software we need to
go from one layer to another.
All the layers are connected
and each layer demands the
fulfillment of the previous
layer.
1.3 Software Engineering
Layered technology is divided into four parts:

• 1. A quality focus:
• It defines the continuous process improvement principles of
software.
• It provides integrity that means providing security to the software so
that data can be accessed by only an authorized person, no outsider
can access the data.
• It also focuses on maintainability and usability.
1.3 Software Engineering
Layered technology is divided into four parts:

• 2. Process:
• It is the foundation or base layer of software engineering.
• It is key that binds all the layers together which enables the
development of software before the deadline or on time.
• Process defines a framework that must be established for the
effective delivery of software engineering technology.
• The software process covers all the activities, actions, and tasks
required to be carried out for software development.
1.3 Software Engineering
Layered technology is divided into four parts:

• 2. Process:
• Process activities are listed below:-
1. Communication: It is the first and foremost thing for the development of
software. Communication is necessary to know the actual demand of the client.
2. Planning: It basically means drawing a map for reduced the complication of
development.
3. Modeling: In this process, a model is created according to the client for better
understanding.
4. Construction: It includes the coding and testing of the problem.
5. Deployment:- It includes the delivery of software to the client for evaluation
and feedback.
1.3 Software Engineering
Layered technology is divided into four parts:

• 3. Method:
• During the process of software development the answers to all
“how-to-do” questions are given by method.
• It has the information of all the tasks which includes communication,
requirement analysis, design modeling, program construction,
testing, and support.
1.3 Software Engineering
Layered technology is divided into four parts:

• Tools:
• Software engineering tools provide a self-operating system for
processes and methods.
• Tools are integrated which means information created by one
tool can be used by another.
1.4 THE SOFTWARE PROCESS
1.4 The Software Process
A process is a collection of activities, actions, and tasks that are
performed when some work product is to be created.

• An activity strives to achieve a broad objective (e.g.,

communication with stakeholders) and is applied regardless of
the application domain, size of the project, complexity of the
effort, or degree of rigor with which software engineering is to
be applied.
• An action (e.g., architectural design) encompasses a set of
tasks that produce a major work product (e.g., an architectural
design model).
• A task focuses on a small, but well-defined objective (e.g.,
conducting a unit test) that produces a tangible outcome.
1.4 The Software Process
• In the context of software engineering, a process is not a rigid
prescription for how to build computer software.
• Rather, it is an adaptable approach that enables the people
• doing the work (the software team) to pick and choose the
appropriate set of work actions and tasks.
• The intent is always to deliver software in a timely manner
and with sufficient quality to satisfy those who have
sponsored its creation and those who will use it.
1.4 The Software Process
• A process framework establishes the foundation for a
complete software engineering process by identifying a small
number of framework activities that are applicable to all
software projects, regardless of their size or complexity.
• In addition, the process framework encompasses a set of
umbrella activities that are applicable across the entire
software process.
• A generic process framework for software engineering
encompasses five activities:
1. Communication.
2. Planning.
3. Modeling.
4. Construction.
5. Deployment.
1.4 The Software Process
1. Communication.
• Before any technical work can commence, it is critically important to
communicate and collaborate with the customer (and other
stakeholders)
• The intent is to understand stakeholders’ objectives for the project and
to gather requirements that help define software features and functions.
2. Planning.
• Any complicated journey can be simplified if a map exists.
• A software project is a complicated journey, and the planning activity
creates a “map” that helps guide the team as it makes the journey.
• The map—called a software project plan—defines the software
engineering work by describing the technical tasks to be conducted, the
risks that are likely, the resources that will be required, the work
products to be produced, and a work schedule.
1.4 The Software Process
3. Modeling.
• Whether you’re a landscaper, a bridge builder, an aeronautical engineer, a
carpenter, or an architect, you work with models every day.
• You create a “sketch” of the thing so that you’ll understand the big picture—
what it will look like architecturally, how the constituent parts fit together,
and many other characteristics.
• If required, you refine the sketch into greater and greater detail in an effort
to better understand the problem and how you’re going to solve it.
• A software engineer does the same thing by creating models to better
understand software requirements and the design that will achieve those
requirements.
1.4 The Software Process
4. Construction.
• This activity combines code generation (either manual or automated)
and the testing that is required to uncover errors in the code.
5. Deployment.
• The software (as a complete entity or as a partially completed
increment) is delivered to the customer who evaluates the delivered
product and provides feedback based on the evaluation.

These five generic framework activities can be used during the

development of small, simple programs, the creation of large Web
applications, and for the engineering of large, complex computer-
based systems. The details of the software process will be quite
different in each case, but the framework activities remain the same.
1.4 The Software Process
• For many software projects, framework activities are applied
iteratively as a project progresses.
• That is, communication, planning, modeling, construction, and
deployment are applied repeatedly through a number of project
iterations.
• Each project iteration produces a software increment that
provides stakeholders with a subset of overall software
features and functionality.
• As each increment is produced, the software becomes more
and more complete.
1.4 The Software Process
• Software engineering process framework activities are
complemented by a number of umbrella activities.
• In general, umbrella activities are applied throughout a software
project and help a software team manage and control progress,
quality, change, and risk.
• Umbrella activities are a series of steps or procedures followed
by a software development team to maintain the progress,
quality, changes, and risks of complete development tasks.
1.4 The Software Process
Typical umbrella activities include:

1. Software project tracking and control—allows the software

team to assess progress against the project plan and take
any necessary action to maintain the schedule.
2. Risk management—assesses risks that may affect the
outcome of the project or the quality of the product.
3. Software quality assurance—defines and conducts the
activities required to ensure software quality.
4. Technical reviews—assesses software engineering work
products in an effort to uncover and remove errors before
they are propagated to the next activity.
1.4 The Software Process
Typical umbrella activities include:

1. Measurement—defines and collects process, project, and

product measures that assist the team in delivering software
that meets stakeholders’ needs; can be used in conjunction
with all other framework and umbrella activities.
2. Software configuration management—manages the effects
of change throughout the software process.
3. Reusability management—defines criteria for work product
reuse (including software components) and establishes
mechanisms to achieve reusable components.
4. Work product preparation and production—encompasses
the activities required to create work products such as
models, documents, logs, forms, and lists.
1.5 SOFTWARE ENGINEERING
PRACTICE
1.5 Software Engineering Practice
1.5.1 The Essence of 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).
(How to Solve It, George Polya [Pol45])

• In the context of software engineering, these commonsense

steps lead to a series of essential questions [adapted from
Pol45]
1.5.1 The Essence of Practice
1. Understand the problem.
Understanding isn’t always that easy. It’s worth spending a little time
answering a few simple questions:

1. Who has a stake in the solution to the problem? That is,

who are the stakeholders?
2. What are the unknowns? What data, functions, and
features are required to properly solve the problem?
3. Can the problem be compartmentalized? Is it possible to
represent smaller problems that may be easier to
understand?
4. Can the problem be represented graphically? Can an
analysis model be created?
1.5.1 The Essence of Practice
2. Plan the solution. Now you understand the problem (or so you
think) and you can’t wait to begin coding. Before you do, slow down
just a bit and do a little design:

1. 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, and
features that are required?
2. Has a similar problem been solved? If so, are elements of
the solution reusable?
3. Can sub-problems be defined? If so, are solutions readily
apparent for the sub-problems?
4. Can you represent a solution in a manner that leads to
effective implementation? Can a design model be created?
1.5.1 The Essence of Practice

A design model is the

means to describe a
system's implementation
and source code in a
diagrammatic fashion.
It has two advantages:
simpler representation and
it can be quickly
understood.
1.5.1 The Essence of Practice
3. Carry out the plan. The design you’ve created serves as a
road map for the system you want to build. There may be
unexpected detours, and it’s possible that you’ll discover an
even better route as you go, but the “plan” will allow you to
proceed without getting lost.

1. Does the solution conform to the plan? Is

source code traceable to the design model?
2. Is each component part of the solution
provably correct? Have the design and code
been reviewed, or better, have correctness
proofs been applied to the algorithm?
1.5.1 The Essence of Practice
4. Examine the result. You can’t be sure that your solution is perfect,
but you can be sure that you’ve designed a sufficient number of tests
to uncover as many errors as possible.

1. Is it possible to test each component part of the solution?

Has a reasonable testing strategy been implemented?
2. Does the solution produce results that conform to the data,
functions, and features that are required? Has the software
been validated against all stakeholder requirements?

It shouldn’t surprise you that much of this approach is common sense.

In fact, it’s reasonable to state that a commonsense approach to
software engineering will never lead you astray.
 1.5.2 General Principles
• The dictionary defines the word principle as “an important
underlying law or assumption required in a system of
thought.”

The First Principle: The Reason It All Exists

• A software system exists for one reason: to provide value to
its users.
• All decisions should be made with this in mind.
• Before specifying a system requirement, before noting a
piece of system functionality, before determining the
hardware platforms or development processes, ask
yourself questions such as: “Does this add real value to
the system?” If the answer is “no,” don’t do it.
• All other principles support this one.
 1.5 Software Engineering Practice
The Second Principle: KISS (Keep It Simple, Stupid!)
• Software design is not a disorganized process.
• There are many factors to consider in any design effort.
• All design should be as simple as possible, but no simpler.
• This facilitates having a more easily understood and easily
maintained system.
• This is not to say that features, even internal features, should
be discarded in the name of simplicity.
• Indeed, the more elegant designs are usually the more simple
ones. Simple also does not mean “quick and dirty.”
• In fact, it often takes a lot of thought and work over multiple
iterations to simplify.
• The payoff is software that is more maintainable and less
error-prone.
1.5 Software Engineering Practice
• A clear vision is essential to the success of a software project.
Without one, a project almost unfailingly ends up being “of
two [or more] minds” about itself.
• Without conceptual integrity, a system threatens to become a
patchwork of incompatible designs, held together by the
wrong kind of screws
• Compromising the architectural vision of a software system
weakens and will eventually break even the well-designed
systems.
• Having an empowered architect who can hold the vision and
enforce compliance helps ensure a very successful software
project.
1.5 Software Engineering Practice

The software
architecture of a
system represents the
design decisions
related to overall
system structure and
behavior.
1.5 Software Engineering Practice
1.5 Software Engineering Practice
The Fourth Principle: What You Produce, Others Will
Consume
• So, always specify, design, and implement knowing someone
else will have to understand what you are doing.
• The audience for any product of software development is
potentially large.
• Specify with an eye to the users.
• Design, keeping the implementers in mind.
• Code with concern for those that must maintain and extend
the system.
• Someone may have to debug the code you write, and that
makes them a user of your code.
• Making their job easier adds value to the system.
 1.5 Software Engineering Practice
The Fifth Principle: Be Open to the Future

• A system with a long lifetime has more value.

• In today’s computing environments, where specifications change on a
moment’s notice and hardware platforms are obsolete just a few months
old, software lifetimes are typically measured in months instead of years.
• However, true “industrial-strength” software systems must endure far
longer.
• To do this successfully, these systems must be ready to adapt to these and
other changes.
• Systems that do this successfully are those that have been designed this way
from the start.
• Never design yourself into a corner. Always ask “what if,” and prepare for all
possible answers by creating systems that solve the general problem, not
just the specific one.
• This could very possibly lead to the reuse of an entire system.
 1.5 Software Engineering Practice
The Sixth Principle: Plan Ahead for Reuse
• Reuse saves time and effort.
• Achieving a high level of reuse is arguably the hardest goal to accomplish in
developing a software system.
• The reuse of code and designs has been proclaimed as a major benefit of
using object-oriented technologies.
• However, the return on this investment is not automatic.
• To leverage the reuse possibilities that object-oriented [or conventional]
programming provides requires forethought and planning.
• There are many techniques to realize reuse at every level of the system
development process
• Planning ahead for reuse reduces the cost and increases the
value of both the reusable components and the systems into
which they are incorporated.
 1.5 Software Engineering Practice
• The Seventh principle: Think!
• This last principle is probably the most overlooked.
• Placing clear, complete thought before action almost always
produces better results.
• When you think about something, you are more likely to do it
right.
• You also gain knowledge about how to do it right again.
• If you do think about something and still do it wrong, it
becomes a valuable experience.

• If every software engineer and every software team simply

followed Hooker’s seven principles, many of the difficulties we
experience in building complex computer-based systems would
be eliminated.
1.6 SOFTWARE MYTHS

Read page
21-25 from
book