CS4433 Assessment

Component Weight

Class test x 2 15%

Term project 20%

Mini-Assignment + Quiz 5%

Examination 60%
Project Groups - circulated
• Multi-phase project, roughly broken into several
deliverables:
• Deliverable 1: Requirements Elicitation Report
• Deliverable 2: Requirements Analysis
• Deliverable 3: Architectural Design
• Deliverable 4: Object/Component Design
• Deliverable 5: Coding/Implementation
• Deliverable 6: Testing and Demo (Final Presentation)
Text Books
• No single prescribed book for CS4433
• Recommended readings are:
1. Software Engineering
Author: Sommerville (at least 8th edition).
Publisher: Addison Wesley
2. Bernd Bruegge, Allen Dutoit: “Object-Oriented Software Engineering:
Using UML, Patterns, and Java”, Prentice Hall, 2003.
3. Applying UML and Patterns: An Introduction to Object-Oriented Analysis
and Design and Unified Process, 2nd ed., C. Larman
4. Grady Booch, James Rumbaugh, Ivar Jacobson, “The Unified Modeling
Language User Guide”, Addison Wesley, 1999. Good reference for UML
5. Additional books may be recommended during individual lectures
Outline – Today’s Lecture
Introduction to Software Engineering (SWE)
 Professional software development
• What, Why, How of software engineering?
• FAQs about SWE
• Essential Attributes of good SW
• Few definitions
 Software engineering ethics
• Brief introduction to ethical issues that affect software engineering
 Modeling complex systems
• Functional vs. Object-oriented decomposition
 Software Lifecycle Modeling
 Software Reuse with: (1) Design Patterns (2) Frameworks
Introduction
• More and more, individuals and societies rely on advanced software
systems.
• Economies of ALL developed countries are depended on “software”.
• More and more systems are software controlled
• Centralized/desktop-based systems TO Distributed systems
• Web-based systems  Cloud-based systems
• More and more items are becoming software controlled
• Internet of Things (IoT)  Internet of Everything (IoE)
• Expenditure of software represents a significant portion of GNP in developed
countries.
• GNP vs. GDP?
• SWE is concerned with theories, methods (techniques), and tools for
professional software development.
Software Costs
• Software costs dominate computer system (hardware) costs
• The costs of software running of company PCs are greater than the
hardware cost.
• Software costs more to maintain than it does to develop
• For systems with very long life, maintenance costs may be several
times development costs.
• SWE is concerned with cost-effective software development
WHY Software Engineering?
(1) Costs
• 13 software projects totalling $90 million. Delivered, but never
successfully used
Take a look at the Standish Report
45%
(The “Chaos” Report) – On Thuto
>> Resources Used as delivered
2%
Usable w. rework
Paid for, but
3% not delivered
Used w. extensive rework, 30%
but later abandoned
20%

• Question: What’s the cause of this?

WHY Software Engineering?
(2) Complexity
• Many sources, but size is key.
• UNIX OS contains over 4 million LOC
• Windows XP contains over 10^8 LOC
• Software engineers should:
• Adopt a systematic and organized approach to their work
• Use appropriate tools and techniques depending on
• the problem at hand
• the development constraints
• resources available
• SWE is concerned with managing this complexity.
Software Engineering: A problem solving activity
• Analysis: Understand the nature of the problem and break it into
pieces
• This is called object identification.
• Synthesis: Put the pieces together into a large structure (the system)
• This is called system integration.
• For problem solving we use:
• Techniques (methods)
• Formal procedures for producing results using well-defined notation, e.g. Algorithms
• Methodologies:
• Collection of techniques applied across software development and unified
• Tools:
• Instrument or automated systems (e.g. CASE tools) used to accomplish a technique
What is Software Engineering?
Definition (1):
• Software Engineering is a collection of techniques, methodologies and tools
that help with the production of

• A high quality software system

• With a given budget
• Before a given deadline

while change(s) occur(s).

FAQS about software engineering (1)
Question Answer
What is software? • Computer programs and associated documentation.
• Software products may be developed for a particular customer (Bespoke
or custom software) or may be developed for a general market (generic
software)
What are the attributes of Good software should:
good software? • deliver the required functionality and performance to the user
• Be maintainable, dependable, efficient and usable
What is software SWE is an engineering discipline that is concerned with all aspects of software
engineering? production
What are the fundamental Software specification, software development, software validation, and
software engineering software evolution
activities?
What are key challenges (1) Coping with increasing diversity,
facing software (2) Demands for reduced delivery times,
engineering? (3) Developing trustworthy software
FAQS about software engineering (2)
Question Answer
What are the best All software system projects must be professionally managed and
software engineering developed, BUT:
techniques and Different techniques are appropriate for different types of systems
methods?
What is the difference Computer Science focuses more on the theories and fundamentals
between software of computing whereas, software engineering is concerned with
engineering and the practicalities of developing and delivering useful software.
computer science?

What differences has • The web has led to the availability of software services - SOA
the web made to • The web has led to the possibility of developing highly
software engineering? distributed service-based systems - DSOA
• The web has led to software reuse
Essential Attributes of good software (1)

Maintainability
• Software should be written in such a way that it can evolve to meet the changing
needs of customers.
• This is a critical attribute because software change is an inevitable result of a
changing business environment.
Essential Attributes of good software (2)
Dependability
• Software dependability has a range of other dimensions, including:
• Reliability, Availability, Security, Safety, Robustness
• Reliability: Strong enough to withstand or overcome intellectual challenges or adversity
• Availability: the ability of the system to deliver services when requested
• Security: Malicious users (e.g. hackers) should not be able to access or damage a secure
system. E.g.
• Perform Database Vulnerability Scanning
• Perform Penetration Testing on systems
• Safety: the ability of the system to operate with catastrophic failure
• A robust system will not be broken by power failures – and should be able to restart
automatically when power returns – a non-robust system will need to be manually
restarted by a person
• A dependable software should not cause physical or economic damage in the event of
system failure.
Essential Attributes of good software (3)

Efficiency

• Software should not make wasteful use of system resources such as

memory and processor cycles.
• Efficiency would therefore include characteristics such as:
• Responsiveness
• Processing time
• Memory utilization
• Space requirements
Essential Attributes of good software (4)

Usability

• Software must be usable, without undue (much/excessive)

effort by the type of user for whom it is designed.
• It means therefore that, it must have:
• an appropriate user interface.
• an adequate documentation.
• It must be understandable and compatible with other systems
that the user uses
Software products
• Generic products
• Stand-alone systems that are marketed and sold to any customer.
• A.K.A Commercial-Off-The-Shelve (COTS)
• Specification of what the software should do is owned by the software
developer and decisions on software change are made by the developer
• Customized products
• Software that is commissioned by a specific customer to meet their own
needs
• Specification is owned by the customer for the software, and the customer
can be decisions of software changes required.
• A.K.A Bespoke software
Definition 2: Software engineering
• Software engineering is an engineering discipline that is concerned with all
aspects of software production from the early stages of system
specification through to maintaining the system after it has gone into use.
• Engineering discipline
• Using appropriate theories and methods to solve computing problems
• – bearing in mind organizational and financial constraints
• All aspects of software production
• Not just technical process of development
• Also, project management and development of tools and methods to support software production
Software process activities
• Software specification – where customers and engineers
define the software that is to be produced and constraints
on its operation.
• Software development - where the software is designed
and programmed.
• Software validation – where the software is checked to
ensure that it is what the customer requires
• Software evolution – where the software is modified to
reflect changing customer and market requirements
General Issues that affect software
• Heterogeneity
• Modern software systems are required to operate as distributed systems, across
networks that include different types of computing and mobile devices.
• Business and social change
• Business and societies change quickly as emerging economies develop, and new
technologies become available
• They need to be able to change their existing software and to rapidly develop new
software.
• Security and trust
• As software is intertwined with all aspects of our lives, it is essential that we can
trust that software.
• Scale
• Software has to be developed across a wide range of scales –
• Very Small scales - embedded systems, systems within wearable devices
• Large scales – Internet-scale, Cloud-based systems that have global community
Software engineering diversity
• There are many different types of software systems and
there is no universal set of software techniques that is
applicable to all of these.
• The software engineering methods and tools used depend
on the:
• (1) Type of application being developed
• (2) The requirements of the customer, and
• (3) The background of the development team
Application types
• Stand-alone applications
• Run on a local computer, e.g. PC
• Include all necessary functionality; do not need to be connected to a network
• Interactive transaction-based applications
• Web applications, e.g. e-commerce applications
• Embedded control systems
• Control systems that control and manage hardware devices
• Batch processing systems
• Business systems designed to process data in large batches
• They process large numbers of individual inputs to create corresponding outputs
• Entertainment systems
• Systems for modelling and simulation
• Developed by scientists and engineers to model physical processes or situations
• Data collection systems
• Collect data from their environment using sensors and send that data to other systems for
processing
Software Engineering Ethics
Software engineering ethics
• SWE involves wider responsibilities than simply the
application of technical skills.
• Software engineers must behave in an honest and
ethically responsible way if they are to be respected as
professionals.
• Ethical behaviour is more than simply upholding the law,
but involves morally correct principles.
Issues of professional responsibility
• Confidentiality
• Software engineers should respect the confidentiality of their employees or
clients irrespective of whether or not a formal confidentiality agreement has been
signed or not.
• Competence
• Software engineers should not misrepresent their level of competence.
• They should not knowingly accept work which is outwith their competence.
• Intellectual property rights
• Software engineers should be aware of the local laws governing the use of IP such
patents, copyright, etc.
• They should be careful to ensure that the IP of employers and clients is protected.
• Computer misuse
• Software engineers should not use their technical skills to misuse other people’s
computers.
• Computer misuse ranges from trivial activities like game playing on an employer’s
machine to deliberate dissemination of viruses.
ACM/IEEE Code of Ethics
• Professional societies like the ACM/IEEE have cooperated to produce and
publish a code of ethical practice for software engineers.
• Members of these organizations sign up to the code of practice when they join.
• ACM/IEEE Code contains eight (8) Principles related to the behaviour and
decisions made by professional software engineers: Practitioners, Educators,
Managers, Supervisors, Policy makers, and Students of the profession.
• 8 principles:
• Public, Client and Employer, Product, Judgment, Management, Profession, Colleagues, Self
• The 8 principles are related to the behaviour and decisions made by SWE professionals.
• Find it here:
• https://www.acm.org/code-of-ethics
ACM/IEEE Code of Ethics (1)
Principle Description
PUBLIC SW engineers shall act consistently with the public interest.

CLIENT & SW engineers shall act in a manner that is in the best interest of
EMPLOYER their client and employer consistent with the public interest.

JUDGMENT SW engineers shall maintain integrity and independence in their

professional judgment.

PRODUCT SW engineers shall ensure that their products and related

modifications meet the highest professional standards possible.

MANAGEMENT SWE managers and leaders shall subscribe to and promote an

ethical approach to the management of SW development and
maintenance.
ACM/IEEE Code of Ethics (2)
Principle Description
COLLEAGUES SW engineers shall be fair to and supportive of their colleagues

PROFESSION SW engineers shall advance the integrity and reputation of the

SWE profession consistent with the public interest

SELF SW engineers shall participate in lifelong learning regarding the

SWE practice and shall promote an ethical approach to the
practice of the profession.
General Software Engineering Principles
Principle 1: 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.
• i.e. Before specifying any system requirement
• Before noting a piece of system functionality
• Before determining the hardware platforms or development process
• the most important question is:

"Does this add real value to the system"? If the answer is NO, don't
do it.
Principle 2: KISS – Keep It Small, Simple

• Software design is not a haphazard process.

• All designs must be as simple as possible.
• Have a more easily understood and easily maintained system.
Principle 3: What you produce, Others will consume
• Someone else will use, maintain, document, or somehow depend on being able to
understand your system.
• Always specify, design, and develop and implement knowing that someone else will have
to understand what you did.
• The audience for any software product is usually large, so engineer software with an eye
to users.
• Specify requirements, keeping designers in mind.
• Design, keeping implementers in mind.
• Code/develop with concern for those that must maintain and extend the system.
• Remember, someone may have to debug the code you have written, and that makes them a user of
your code.
Principle 4: Maintain the Vision
• A clear vision is essential to the success of a software project.
• Without a clear vision, a software project can easily end-up losing real
purpose it was originally meant to address.
• Have an architectural vision (high-level concept) and stick to it throughout.
Principle 5: Plan Ahead for Reuse
• Planning ahead for reuse reduces the cost and increases the value of both the reusable
components and the systems into which they are incorporated.
• Reuse saves time and effort.
• Object-oriented analysis and design (OOA/D) (as opposed to conventional programming
styles) is the one that puts us closer to having re-usable designs and implementations.
Software vs. Hardware
1. Software does not “wear out”, but
deteriorates, whereas Hardware wears out
• Refer to:
• (a) Failure curve for hardware
• (b) Failure curve for software
Failure Curve for Hardware Failure Curve for Hardware

• This figure shows failure rate as a function

of time for hardware.
• This curve is called the "bathtub curve".
• It indicates that hardware exhibits relatively
high failure rates early in its life - these
failures are mostly attributed to design or
manufacturing defects.
 The defects are corrected and failure rate
drops to a steady state level for some
period of time.
• As time passes, the failure rate rises again
as hardware components suffer from the
cumulative effects of dust, vibration, abuse,
temperature extremes and many other
environmental problems.
• Simply stated, hardware begins to wear out
Failure Curve for Software Failure Curve for Software –
• Software is not susceptible to the Idealized curve
environmental problems that cause
hardware to wear out.
• The theoretical failure rate curve for
software takes the form of the
"idealized curve".
• Undiscovered defects will cause high
failure rates early in the life of a software
program.
• However, these are corrected and the
curve flattens as shown.
• All in all, software does not wear out,
but it does deteriorate due to change.
• Key point is: If you want to reduce software
deterioration, you will have to do better software
design.
Failure Curve for Software Failure Curve for Software -
• The seeming contradiction can be best explained Actual curve
by considering the actual failure curve for
software.
• During its lifetime, software undergoes several
changes.
• As changes are made, it is likely that errors
will be introduced, causing the failure rate
curve to spike as shown in the actual curve.
• Before the curve can return to the original
steady-state failure rate, another change is
requested, causing the curve to spike again.
• Slowly, the minimum failure rate level begins to
rise-hence software deteriorating due to
change.
2. Spare parts in … spare parts in
Hardware vs. Software
• When a hardware • There are no software spare parts
• Every software failure indicates an error in
component wears out, it is design or in the process through which the
replaced by a spare part design was translated into a machine
executable code
(over the shelf). • Therefore, software maintenance tasks that
accommodate requests for change still
involve considerably more complexity than
hardware maintenance.
3. Software is developed or engineered; it is
not manufactured in the classical sense

• In both hardware and software development, high quality is

achieved through good design.
• But the manufacturing phase for hardware can introduce quality
problems that are non-existent for software or if they exist they can be
corrected easily because software is flexible.
4. Component- … in Software
based development • A software component should be
in Hardware vs. designed and implemented so that it
can be reused in many different
• Standard screws and off-the- programs.
shelf integrated circuits (IC) • Apply encapsulation such that
reusable components can
• Reusable components enable encapsulate both data and
the engineer to concentrate processing that is applied to the data,
on truly innovative elements enabling the software engineer to
of the design – parts of the create new applications for reusable
design that represent parts
something new. • Make use of existing libraries/APIs of
reusable components
• In hardware, component
• Leave one library/API yourself for
reuse is a natural part of the others to use in the future
engineering process.
Important definitions ….

• A new system is when there is no existing system.

• A replacement system is when a system is built to replace an existing
system.
• A legacy system is an existing system that is not being replaced, but
must interface to the new system.
• In requirements analysis it is important to distinguish between:
• Features of the current (old) system
• Proposed new features