ECNG3023: Introduction to Software Engineering

1
ECNG3023 Introduction to Software Engineering

• Kevon Andrews
• Rm. 329
• keandrews_at_eng.uwi.tt
• Ph 662-2002 x3156
• Open Hours

2
EE29B Introduction to Software Engineering

• This course is examined by coursework (40) and
  by examination (60)
• There will be three mini-projects, the first one
  will be an individual project and the rest done
  in groups. Groups are to be 3-4 students.

3
What is Software Engineering?

• The IEEE Computer Society defines software
  engineering as
• The application of a systematic, disciplined,
  quantifiable approach to the development,
  operation and maintenance of software that is,
  the application of engineering to software.
• The study of approaches as above.

4
Problem solving (Analysis)

• We typically solve a problem by analysing it,
  that is by breaking it down into pieces.

Problem
1
4
2
3
4
1
2
3
5
Problem solving (Synthesis)

• Once we have analysed the problem, we must
  construct our solution from components that
  address the problem's various aspects

4
1
2
3
1
4
2
3
Solution
6
How are software projects different?

• Invisibility
• No physical presence
• Flexibility
• After all it's software
• Complexity
• no physical constraints

7
The Software Iceberg
The Product
What the customers see
Code Data Definitions Databases
Specifications Plans Standards
Procedures Manuals
Simulators Development Systems Automatic test
Equipment
Compilers, Operating Systems, Utilities
Configuration Management
DBMS
CASE
8
Key Issues facing Software Developers

• Unfulfilled demand
• Increasing complexity
• Greater customer expectations
• Rapid obsolescence
• Increasing competition
• Shorter product cycle times
• Producing more with less
• Evolving methods and tools

9
Terminology for describing bugs

• A fault occurs when a human makes a mistake,
  called an error in performing some software
  activity.
• A failure is a departure from the systems
  required behaviour It can be discovered before
  or after system delivery or during operation and
  maintenance. Since requirements documents can
  contain faults, failures can exist even though
  the system is performing as specified!

10
What does project failure mean?

• Late delivery? No delivery at all?
• Not delivering what was agreed to or what was
  announced?
• Over budget?
• Not meeting revenue expectations?
• Quality below expectations?

11
Some reasons projects fail

• Not understanding what the product must do
• Uncontrolled changes
• Optimistic thinking
• Insufficient resources
• Lack of disciplined development
• Confusion about what needs to be done
• Ineffective teamwork
• Failure to consider business needs

12
Some reasons products fail

• Price
• Mature market
• Lack essential capabilities
• Difficult to use
• Unreliable
• Poor developer reputations
• Poor product support

13
Some reasons projects succeed

• Good understanding of the problem to solve
• Good planning and execution
• Extraordinary effort and commitment by
  individuals
• Luck

14
Some reasons products succeed

• Satisfy an unfulfilled need
• Novelty
• Value
• Marketing strategy

15
What is good software?

• Quality of the product?
• Quality of the process?
• Quality in the context of the Business
  Environment?

16
Quality of the product

• Correctness
• Reliability
• Efficiency
• Integrity
• Usability
• Maintainability

• Testability
• Flexibility
• Portability
• Reusability
• Interoperability

17
Quality of the product

• Correctness
• extent to which program fulfils its specification
• Reliability
• systems ability not to fail
• Efficiency
• use of resources, e.g. processor time, storage
• Integrity
• protection of program from unauthorised access
• Usability
• ease of software

• Maintainability
• effort required to locate and fix a fault in
  program within its operating environment
• Testability
• ease of testing program, to ensure it is
  error-free and meets its specification
• Flexibility
• Ease of making changing required by changes in
  the operating environment

18
Quality of the product

• Portability
• Effort required to transfer a program from one
  environment to another
• Reusability
• Ease of reusing software in a different context
• Interoperability
• Effort required to couple system to another system

19
Quality of the process

• many activities can affect ultimate product
  quality
• By modelling a process, we can examine it and
  look for improvements
• Where and when are we likely to find a particular
  kind of fault?
• How can we find faults earlier in the development
  process?
• How can we build in fault tolerance so that we
  can minimize the likelihood that a fault will
  become a failure?
• Are there alternative activities that can make
  our process more effective or efficient at
  assuring quality?

20
Quality in the context of the business environment

• A view in terms of the products and services
  being provided by the business in which the
  software is embedded.
• i.e., we look at the business value.
• can be as simple as Return On Investment (ROI) or
  some more elaborate measure.

21
Who does software engineering?

• Customer
• Sponsors system
• development

User Uses system
Developer Builds system
Needs
Software system
22
Systems Approach

• Elements of a system
• Activities and Objects
• Relationships and the System Boundary
• Consider nested systems and system
  interrelationships

23
Activities and Objects

• Distinguish between activities and objects
• activity is something that happens in a system.
• Usually described as event initiated by trigger
• Transforms one thing to another by changing a
  characteristic, e.g.
• data element moved from one location to another
• data element is changed from one value to another
• data element is combined with other data to
  supply input for yet another activity
• object or entity is element involved in the
  activity.
• Usually related in some way arranged in a table
  or grouped as records with pre-defined format

24
Relationships and the System Boundary

• A system is defined as a collection of things
• a set of entities,
• a set of activities,
• a description of the relationships among entities
  and activities,
• and a definition of the boundary of the system.
• Boundary states what is included and what is not
• Examples the human respiratory system, a
  paycheck production system

25
Nested systems

• It is possible for one system to exist within
  another system, e.g. sensor system
• One can have various functions of the sensors
  nested within each other.
• Boundary of system is important to see what is
• within the system
• outside of the system
• what crosses the boundary of the system

26
An analogy of software engineering

• Determining and analysing requirements
• Producing and documenting the design
• Detailed specifications
• Identifying and designing components

• Requirements analysis and definition
• System design
• Program design

27
Analogy ...

• Building components
• Testing components
• Integrating components
• Making final modifications
• Continuing maintenance

• Writing programs
• Unit testing
• Integration testing
• System testing
• System delivery
• Maintenance

28
7 Factors Altering S/ware Engineering
29
Key factors that changed SWE

• Criticality of time to market for commercial
  products
• Business must ready their new products and
  services before their competitors do
• Shifts in the economics of computing
• Lower hardware costs and greater development and
  maintenance costs
• Availability of powerful desktop computing
• More development power in hands of users,
  therefore software engineers are likely to be
  building more complex systems than before
• Extensive networks available
• Makes it easier for users to find information
  without special applications e.g. searching WWW
  is quick, easy and effective

30
Key factors that changed SWE

• Availability and adoption of object-oriented
  technology
• Makes available reusable modules for immediate
  and speedy inclusion in new applications
• Graphical User Interfaces (GUIs)
• Helps to put a friendly face (appearance) on
  complicated applications
• Unpredictability of the waterfall method
• Developing subsystems in parallel requires
  development process very different from waterfall
  model

31
Discipline of Software Engineering

• Abstraction
• Analysis and Design methods and Notations
• User Interface Prototyping
• Software Architecture
• Software Process
• Reuse
• Measurement
• Tools and Integrated Environments

32
Abstraction

• Abstraction is a description of the problem at
  some level of generalisation that allows us to
  concentrate on the key aspects of the problem
  without getting involved in the difficulties of
  the details.
• Typically involves identifying classes of objects
  that allow us to group items together so we
• Can deal with fewer things, and
• Concentrate on the commonalities of items in each
  class

33
Analysis and Design Methods and Notations

• These offer a
• Communication medium
• Communication and documentation of decisions
  among development team
• Ability to build models
• Ability to check models for completeness and
  consistency
• Reuse requirements and design components from
  previous projects

34
User interface Prototyping

• Prototyping is building a small version of a
  system, usually with limited functionality
• Prototypes can be used to
• Help the user/customer identify the key
  requirements of a system
• Demonstrate feasibility of a design or approach
• Usually an iterative process
• Build prototype
• Evaluate it with user and customer feedback
• Consider how changes might improve product or
  design
• Build another prototype OR iteration ends when
  developer and customer are satisfied with solution

35
Software architecture

• Importance of overall architecture of system is
• ease of implementation and testing
• speed and effectiveness of maintenance and
  change.
• The quality of the architecture can make or break
  a system.
• Systems architecture describes system in terms
  of
• set of architectural units, and
• map of how units relate to each other

36
Software architecture (continued)

• Five ways of decomposing a system
• Modular based upon assigning functions to
  modules
• Data-oriented based upon external data
  structures
• Event-oriented based upon events that the system
  must handle
• Outside-in based upon user inputs to the system
• Object-Oriented based upon identifying classes
  of objects and their interrelationships

37
Software process
38
Reuse

• We take advantage of commonalities across
  applications by reusing items from previous
  development.
• Reuse pertains not only to code but to design,
  test data, requirements etc.

39
Measurement

• Measurement is a driving force in software
  engineering research
• improving our processes, resources and methods so
  that we produce and maintain better products.
• But sometimes we express measurements generally,
  with no quantitative description.
• We would like to quantify
• where we can and what we can,
• describe our actions and outcomes in a common
  mathematical language that allows us to compare
  progress across disparate projects.

40
Tools and integrated environments

• Issues in tool integration
• Platform the ability of tools to interoperate on
  a heterogeneous network
• Presentation commonality of the user interface
• Process linkage between the tools and the
  development process
• Data the way the tools share data
• Control the ability of one tool to notify and
  initiate action in another.

41
Therac-25 (from IEEE Computer July 1993)

• Computers are increasingly being introduced into
  safety-critical systems and as a consequence,
  have been involved in accidents. Some of the most
  widely cited software-related accidents in
  safety-critical systems involved a computerized
  radiation therapy machine called the Therac-25.
• Between June 1985 and January 1987, six known
  accidents involving massive overdoses by the
  Therac-25 --- with resultant deaths and seriious
  injuries.

42
Therac-25 routines(from IEEE Computer July 1993)