SOFTWARE ENGINEERING

BY DONALD PHIRI
OUTLINE

 Software
 Relevance
 Categories
 Software Engineering
 Why engineering
 Software process
 Adapting a process model
 Software myths
 How software is engineered
Software

 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.
 Characteristic features
 Its characteristics that make it different from other things human being build.
 Features of such logical system: Software is developed or engineered, it is not manufactured in
the classical sense which has quality problem.
 Software doesn't "wear out.” but it deteriorates (due to change). Hardware has bathtub curve
of failure rate ( high failure rate in the beginning, then drop to steady state, then cumulative
effects of dust, vibration, abuse occurs).
 Modern reusable components encapsulate data and processing into software parts to be reused
by different programs. E.g. graphical user interface, window, pull-down menus in library et
Types

 Generic Software: Stand-alone systems that are marketed and sold to any customer who
wishes to buy them. Examples – PC software such as editing, graphics programs, project
management tools; CAD software; software for specific markets such as appointments
systems for dentists.
 Customized products: Software that is commissioned by a specific customer to meet their
own needs. Examples – embedded control systems, air traffic control software, traffic
monitoring systems.
Relevance: why we need software

 The economies of ALL developed nations are dependent on software.

 More and more systems are software controlled ( transportation, medical,
telecommunications, military, industrial, entertainment, banks, market platforms etc).
Pictorial view of software failure rate
Professional Software Development
Software engineering diversity

 Stand-alone applications
 Interactive transaction-based applications
 Embedded control systems
 Batch processing systems
 Entertainment systems
 AI driven systems
 Systems for modeling and simulation
 Data collection and analysis systems
Software Engineering

 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.
 The IEEE definition:
 Software Engineering: The application of a systematic, disciplined, quantifiable approach
to the development, operation, and maintenance of software; that is, the application of
engineering to software.
 Other sources:
 Engineering is the application of an empirical, scientific approach to finding efficient,
economic solutions to practical problems.
Why engineering not just production

 More and more, individuals and society rely on advanced software systems.
 We need to be able to produce reliable and trustworthy systems economically and quickly.
 It is usually cheaper, in the long run, to use software engineering methods and techniques
for software systems rather than just write the programs as if it was a personal
programming project.
 For most types of system, the majority of costs are the costs of changing the software after
it has gone into use.
 Issues of complexity, reusability, scalability are best handled by engineering approach.
 When we get these things right, and many teams do, we see greater productivity, less stress
and burnout in team members, higher quality in design, and more resilience in the systems
that we create.
Continued

 Engineering amplifies our ability to be creative, to make useful things, to proceed with
confidence and quality. It allows us to explore ideas and ultimately to scale our ability to
create things so that we can build ever bigger, more complex systems.
 The systems that we build please their users more.
 We see dramatically fewer bugs in production, and teams that employ these ideas find it
significantly easier to change almost any aspect of the systems that they work on as their
learning evolves.
 Engineering is about learning and mastering.
Attributes of a good software

 Maintainability and scalability: Software should be written in such a way so that it can
evolve to meet the changing needs of customers. This is a critical attribute because software
change is an inevitable requirement of a changing business environment.
 Dependability and security: Software dependability includes a range of characteristics
including reliability, security and safety. Dependable software should not cause physical or
economic damage in the event of system failure. Malicious users should not be able to access
or damage the system.
 Efficiency: Software should not make wasteful use of system resources such as memory and
processor cycles. Efficiency therefore includes responsiveness, processing time, memory
utilisation, etc.
 Acceptability: Software must be acceptable to the type of users for which it is designed. This
means that it must be understandable, usable and compatible with other systems that they use.
Software engineering layered model
Software engineering as a layered model.

 Any engineering approach must rest on organizational commitment to quality which

fosters a continuous process improvement culture.
 Process layer as the foundation defines a framework with activities for effective delivery
of software engineering technology. Establish the context where products (model, data,
report, and forms) are produced, milestone are established, quality is ensured and change is
managed.
 Method provides technical how-to’s for building software. It encompasses many tasks
including: communication, requirement analysis, design modeling, program construction,
testing and support.
 Tools provide automated or semi-automated support for the process and methods.
Software process: how the journey starts

 Starts with having any idea, new or already existing

 Need to change things
 Need to solve a problem related to software operations that affect business
 the need to extend the functions and features of an existing application, or the need to
create a new product, service, or system.
 Requires a road map, a process, a step by step approach. (software process)
Software process

 A process is a collection of activities, actions and tasks that are performed when some
work product is to be created.
 It is not a rigid prescription for how to build computer software. Rather, it is an adaptable
approach that enables the people doing the work to pick and choose the appropriate set of
work actions and tasks.
 Purpose of process is 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.
Five Activities of a Generic Process framework

 Communication: communicate with customer to understand objectives and gather requirements.

 Planning: creates a “map” defines the work by describing the tasks, risks and resources, work products and
work schedule.
 Modeling: Create a “sketch”, what it looks like architecturally, how the constituent parts fit together and
other characteristics.
 Construction: code generation and the testing.
 Deployment: Delivered to the customer who evaluates the products and provides feedback based on the
evaluation.
 These five framework activities can be used to all software development regardless of the application
domain, size of the project, complexity of the efforts etc, though the details will be different in each case.
This will lead us to software development life cycle to be discussed later.
 For many software projects, these framework activities are applied iteratively as a project progresses. Each
iteration produces a software increment that provides a subset of overall software features and functionality.
Complementing activities

 Complement the five process framework activities and help team manage and control progress, quality,
change, and risk.
 Software project tracking and control: assess progress against the plan and take actions to maintain the
schedule.
 Risk management: assesses risks that may affect the outcome and quality.
 Software quality assurance: defines and conduct activities to ensure quality.
 Technical reviews: assesses work products to uncover and remove errors before going to the next activity.
 Measurement: define and collects process, project, and product measures to ensure stakeholder’s needs
are met.
 Software configuration management: manage the effects of change throughout the software process.
 Reusability management: defines criteria for work product reuse and establishes mechanism to achieve
reusable components.
Adapting a Process Model

 The process should be agile and adaptable to problems.

 Process adopted for one project might be significantly different than a process adopted from another
project. (to the problem, the project, the team, organizational culture). Among the differences are:
 the overall flow of activities, actions, and tasks and the interdependencies among them
 the degree to which actions and tasks are defined within each framework activity
 the degree to which work products are identified and required the manner which quality assurance
activities are applied the manner in which project tracking and control activities are applied
 the overall degree of detail and rigor with which the process is described
 the degree to which the customer and other stakeholders are involved with the project
 the level of autonomy given to the software team
 the degree to which team organization and roles are prescribed
Prescriptive and Agile Process Models

 The prescriptive process models stress detailed definition, identification, and application of
process activates and tasks.
 Intent is to improve system quality, make projects more manageable, make delivery dates
and costs more predictable, and guide teams of software engineers as they perform the
work required to build a system.
 Unfortunately, there have been times when these objectives were not achieved. If
prescriptive models are applied dogmatically and without adaptation, they can increase the
level of bureaucracy.
 Agile process models emphasize project “agility” and follow a set of principles that lead to
a more informal approach to software process. It emphasizes maneuverability and
adaptability. It is particularly useful when Web applications are engineered.
Engineering meets software development

 How does the practice of software engineering fit in the process activities mentioned
above? Namely, communication, planning, modeling, construction and deployment.
 George Polya outlines the essence of problem solving, suggests:
 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: where mostly things
go wrong
 Who has a stake in the solution to the problem? That is, who are the stakeholders?
 What are the unknowns?
 What data, functions, and features 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?
 Is it a new invention or an update or an upgrade?
Understand the Problem: where mostly things
go wrong
 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?
 Has a similar problem been solved? If so, are elements of the solution reusable?
 Can sub problems be defined?
 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?
 Plan the Solution
Hooker’s General Principles for Software Engineering Practice:
important underlying law

 1: The Reason It All Exists: provide values to users

 2: KISS (Keep It Simple, Stupid! As simple as possible)
 3: Maintain the Vision (otherwise, incompatible design)
 4: What You Produce, Others Will Consume (code with concern for those that must
maintain and extend the system)
 5: Be Open to the Future (never design yourself into a corner as specification and hardware
changes)
 6: Plan Ahead for Reuse
 7: Think! Place clear complete thought before action produces better results.
Software Myths

 Erroneous beliefs about software and the process that is used to build it.
 Affect managers, customers (and other non-technical stakeholders) and practitioners
 Are believable because they often have elements of truth, but …Invariably lead to bad
decisions, therefore …Insist on reality as you navigate your way through software
engineering
Software Myths Examples

 Myth 1: Once we write the program and get it to work, our job is done. Reality: the sooner
you begin writing code, the longer it will take you to get done. 60% to 80% of all efforts are
spent after software is delivered to the customer for the first time.
 Myth 2: Until I get the program running, I have no way of assessing its quality. Reality:
technical review are a quality filter that can be used to find certain classes of software defects
from the inception of a project.
 Myth 3: software engineering will make us create voluminous and unnecessary documentation
and will invariably slow us down. Reality: it is not about creating documents. It is about
creating a quality product. Better quality leads to a reduced rework. Reduced work results in
faster delivery times.
 Many people recognize the fallacy of the myths. Regrettably, habitual attitudes and methods
foster poor management and technical practices, even when reality dictates a better approach.
Legacy Software… reading assignment
Software process assessment
Software process models