ECNG3023: Introduction to Software Engineering - PowerPoint PPT Presentation

Loading...

PPT – ECNG3023: Introduction to Software Engineering PowerPoint presentation | free to download - id: 1de758-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

ECNG3023: Introduction to Software Engineering

Description:

This course is examined by coursework (40%) and by examination (60 ... activity is something that happens in a system. Usually described as event initiated by trigger ... – PowerPoint PPT presentation

Number of Views:14
Avg rating:3.0/5.0
Slides: 43
Provided by: jun89
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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)
About PowerShow.com