Lecture 1
Lecture 1
Lecture 1 1
Nature of
delivering aSoftware
Software functions both as a product and as a vehicle for
product.
•Software as a Product:
•Delivers the computing potential embodied by computer
hardware or networks (software products enable the actual
capabilities of computer hardware or networks).
•It acts as an information transformer by producing, managing,
acquiring, modifying, displaying, or transmitting information.
•Can reside in various devices, including mobile phones, tablets,
desktops, or mainframes. 2
Nature of
• Software
Software as a Vehicle:
• Acts as the basis for the control of the computer (e.g.,
operating systems).
• Facilitates the communication of information (e.g.,
networks).
• Enables the creation and control of other programs (e.g.,
software tools and environments).
3
What is
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 and (3)
documentation that describes the operation and use of the
programs.
4
Software products
• Generic products
• 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 (CAD stands for "Computer-
Aided Design) software; software for specific markets such as
appointments systems for dentists.
• Customized products (Also said Projects)
• Software that is commissioned by a specific customer to meet
their own needs.
• Examples – embedded control systems, air traffic control
software, traffic monitoring systems.
5
Why Software is
Important?
6
Software costs
7
Features of
Software?
• 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 (his refers to the process of creating
software through careful planning, designing, coding, testing, and
maintenance).
• 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).
• Although the industry is moving toward component-based construction
(e.g. standard screws and off-the-shelf integrated circuits), most software
continues to be custom-built. 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 etc.
8
Wear vs.
Deterioration
increased failure
rate due to side effects
Failure
rate
change
actual curve
idealized curve
9
Time
Software
Applications
• 1. System software: such as compilers, editors, file management utilities
• 2. Application software: stand-alone programs for specific needs.
• 3. Engineering/scientific software: Characterized by “number crunching”algorithms. such
as automotive stress analysis, molecular biology, orbital dynamics etc
• 4. Embedded software resides within a product or system. (key pad control of a
microwave oven, digital function of dashboard display in a car)
• 5. Product-line software focus on a limited marketplace to address mass consumer
market. (word processing, graphics, database management)
• 6. WebApps (Web applications) network centric software. As web 2.0 emerges, more
sophisticated computing environments is supported integrated with remote database and
business applications.
• 7. AI software uses non-numerical algorithm to solve complex problem. Robotics, expert
system, pattern recognition game playing 10
Software—New
Categories
• Open world computing—pervasive, ubiquitous, distributed computing due to
wireless networking. How to allow mobile devices, personal computer,
enterprise system to communicate across vast network.
• Netsourcing—the Web as a computing engine. How to architect simple and
sophisticated applications to target end-users worldwide.
• Open source—”free” source code open to the computing community (a
blessing, but also a potential curse!)
• Also … (see Chapter 31)
• Data mining
• Grid computing
• Cognitive machines
• Software for nanotechnologies
11
Software Engineering
Definition
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.
13
FAQ about software engineering
Question Answer
14
Essential attributes of good
software
Product characteristic Description
15
Software Engineering
A Layered Technology
tools
methods
process model
a “quality” focus
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, testing16and
support.
Tools provide automated or semi-automated support for the process and methods.
• 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.
Software Process 17
• 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.
• For many software projects, these framework activities are applied iteratively as
a project progresses. Each iteration produces a software increment that provides a
Five Activities of a
subset of overall software features and functionality.
Generic Process
framework 18
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.
19
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:
Adapting a Process
•the level of autonomy given to the software team
•the degree to which team organization and roles are prescribed
Model 20
•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.
Prescriptive and
Agile Process Models 21
• 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).
The Essence of
Practice 22
• 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?
Understand the
Problem 23
• 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?
Examine the
Result 26
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 27
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.
28
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.
29
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.
30
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.
31
MHC-PMS goals
32
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.
33
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.
34
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.
35
• Mid Term30 marks
• Final Term 50 marks
• Sessional
• Two assignments 5 marks
• Two Quiz 5 marks
• Project 10 Marks
75% attendance is must.
Marks Break Up 36