Software Engineering

BCA-303
Ms. Sunidhi Shrivastava
Assistant Professor
CSA Dept.
ITM University Gwalior
Software Process and Their Characteristics
 Content
• Introduction
• Five Activities of a Generic Process framework
• Umbrella Activities
• Adapting a Process Model
• Prescriptive and Agile Process Models
• Adapting a Process Model
• The Essence of Practice
• Understand the Problem
• Plan the Solution
• Carry Out the Plan
• Software Myths
• Case studies
 Introduction
• 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.

• 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.
 Umbrella 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.
• Work product preparation and production: create work products such as models,
documents, logs, forms and lists.
 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

7
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.
 The Essence of Practice
• 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
• 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?
 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, and features that are required?
• Has a similar problem been solved? If so, are elements of the solution
reusable?
• Can subproblems be defined? If so, are solutions readily apparent for the
subproblems?
• 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 solutions conform to the plan? Is source code
traceable to the design model?
• Is each component part of the solution provably correct? Has
the design and code been reviewed, or better, have correctness
proofs been applied to 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 conform to the data, functions,
and features that are required? Has the software been validated against
all stakeholder requirements?
Hooker’s General Principles for Software Engineering
Practice: important underlying law

Help you establish mind-set for solid software engineering

practice (David Hooker 96).
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.
 Cont..
• 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.
 How It all Starts
• SafeHome:
– Every software project is precipitated by some
business need—
• the need to correct a defect in an existing application;
• the need to the need to adapt a ‘legacy system’ to a changing business
environment;
• the need to extend the functions and features of an existing application, or
• the need to create a new product, service, or system.
 Case studies
• A personal insulin pump
– An embedded system in an insulin pump used by diabetics to maintain
blood glucose control.
• A mental health case patient management system
– A system used to maintain records of people receiving care for mental
health problems.
• A wilderness weather station
– A data collection system that collects data about weather conditions in
remote areas.
 Insulin pump control system
• Collects data from a blood sugar sensor and calculates the
amount of insulin required to be injected.
• Calculation based on the rate of change of blood sugar levels.
• Sends signals to a micro-pump to deliver the correct dose of
insulin.
• Safety-critical system as low blood sugars can lead to brain
malfunctioning, coma and death; high-blood sugar levels have
long-term consequences such as eye and kidney damage.
Insulin pump hardware architecture
Activity model of the insulin
pump
 Essential high-level requirements
• The system shall be available to deliver insulin when
required.
• The system shall perform reliably and deliver the correct
amount of insulin to counteract the current level of blood
sugar.
• The system must therefore be designed and implemented to
ensure that the system always meets these requirements.
A patient information system for mental health care
• A patient information system to support mental health care is a
medical information system that maintains information about patients
suffering from mental health problems and the treatments that they
have received.
• Most mental health patients do not require dedicated hospital
treatment but need to attend specialist clinics regularly where they
can meet a doctor who has detailed knowledge of their problems.
• To make it easier for patients to attend, these clinics are not just run in
hospitals. They may also be held in local medical practices or
community centres.
 MHC-PMS
• The MHC-PMS (Mental Health Care-Patient Management
System) is an information system that is intended for use in
clinics.
• It makes use of a centralized database of patient information
but has also been designed to run on a PC, so that it may be
accessed and used from sites that do not have secure network
connectivity.
• When the local systems have secure network access, they use
patient information in the database but they can download and
use local copies of patient records when they are disconnected.
 MHC-PMS goals
• To generate management information that allows health
service managers to assess performance against local and
government targets.
• To provide medical staff with timely information to support
the treatment of patients.
The organization of the MHC-PMS
 MHC-PMS key features
• Individual care management
– Clinicians can create records for patients, edit the information in the
system, view patient history, etc. The system supports data
summaries so that doctors can quickly learn about the key problems
and treatments that have been prescribed.
• Patient monitoring
– The system monitors the records of patients that are involved in
treatment and issues warnings if possible problems are detected.
• Administrative reporting
– The system generates monthly management reports showing the
number of patients treated at each clinic, the number of patients who
have entered and left the care system, number of patients sectioned,
the drugs prescribed and their costs, etc.
 MHC-PMS concerns
• Privacy
– It is essential that patient information is confidential and is never
disclosed to anyone apart from authorised medical staff and the patient
themselves.
• Safety
– Some mental illnesses cause patients to become suicidal or a danger to
other people. Wherever possible, the system should warn medical staff
about potentially suicidal or dangerous patients.
– The system must be available when needed otherwise safety may be
compromised and it may be impossible to prescribe the correct
medication to patients.
 Wilderness weather station
• The government of a country with large areas of
wilderness decides to deploy several hundred weather
stations in remote areas.
• Weather stations collect data from a set of instruments
that measure temperature and pressure, sunshine, rainfall,
wind speed and wind direction.
– The weather station includes a number of instruments that
measure weather parameters such as the wind speed and
direction, the ground and air temperatures, the barometric
pressure and the rainfall over a 24-hour period. Each of these
instruments is controlled by a software system that takes
parameter readings periodically and manages the data collected
from the instruments.
•
The weather station’s
environment
 Weather information
system
• The weather station system
– This is responsible for collecting weather data, carrying out some
initial data processing and transmitting it to the data management
system.
• The data management and archiving system
– This system collects the data from all of the wilderness weather
stations, carries out data processing and analysis and archives the
data.
• The station maintenance system
– This system can communicate by satellite with all wilderness
weather stations to monitor the health of these systems and provide
reports of problems.
 Additional software
functionality
• Monitor the instruments, power and communication
hardware and report faults to the management system.
• Manage the system power, ensuring that batteries are
charged whenever the environmental conditions permit
but also that generators are shut down in potentially
damaging weather conditions, such as high wind.
• Support dynamic reconfiguration where parts of the
software are replaced with new versions and where
backup instruments are switched into the system in the
event of system failure.
 Assignment
• Which one of the following is not a software process quality?
a) Productivity
b) Portability
c) Timeliness
d) Visibility

• The process of developing a software product using software

engineering principles and methods is referred to as, _______ .

a. Software myths
b. Scientific Product
c. Software Evolution
d. None of the above
• Which one of the following is not an Umbrella Activity that
complements the five process framework activities and help team
manage and control progress, quality, change, and risk.

a) Reusability management
b) Risk management
c) Measurement
d) User Reviews

• Process adopted for one project is same as the process adopted

from another project.

a) True
b) False
[email protected]