MSc OOSE Introduction

1
MSc OOSE Introduction

• Welcome!
• OOSE web page - this is where your notes are
• http//gawain.soc.staffs.ac.uk/modules/levelm/oos
  e/oose.htm
• 14 week module - 2 hrs a week contact 2 hours
  blended
• We are particularly interested in equipping and
  selling all of you with doing software
  engineering skills

2
MSc OOSE Introduction

• A summary of the software engineering skills to
  impart to you-
• How to program using software engineering
  techniques
• Web development skills
• Awareness and use of object oriented methods
• Database integration

3
MSc OOSE Introduction

• Other aspects of software engineering are covered
  by other modules
• Project management/Systems Analysis/Communications
  /Computer hardware and software
• All the above topics come under the umbrella of
  software engineering which sometimes can seem
  confusing until you realise that software
  engineering involves a set of stages and tools

4
Software Engineering Books

• Software Engineering, 5th edition,Ian
  Sommerville,Addison-Wesley.
• Software Engineering - A Practitioners Approach
• Roger Pressman
• Object-Oriented and Classical Software
  Engineering
• Stephen R. Schach

5
Software Engineering

• We need to understand what software engineering
  is and how it came about
• Why use it?
• How to use it - the lifecycles
• Improvements
• Future of software engineering

6
Software engineeringWhat is it?

• An approach to software development to embody the
  same discipline and rigor found in the
  engineering world
• Advantages include
• Speed/productivity
• Re-use
• Measurable

7
Software EngineeringWhy?

• The software crisis, recognised C1969. -
  threatened the progress of the computer industry
• People-time was and still is relatively
  expensive, machine-time is cheap.
• Programming was and still is very time intensive.
• Products need support - this is probably more
  than ever
• Software is complex imagine creating a car with
  no drawings, specifications or planning.

8
Software EngineeringTrends

• The price of computer hardware is still falling
  fast.
• The cost of computer software is still high
• More and more products are incorporating
  microprocessors (and thus software),e.g car
  engines, cameras, TV sets and mobile phones
• Tens of millions of personal computers are in
  use, often in strategic roles.

9
Software EngineeringChallenges

• Personal, corporate, national and international
  economies are increasingly dependent on computers
  and their software.
• Some commercial software is still written in old
  COBOL and has been modified and patched by
  generations of engineers
• Some of our most complex feats of engineering are
  computer programs.

10
Software EngineeringIncorporates programming

• Programming is much more than just writing code.
• Programming involves (at least) the following
  activities-
• Problem analysis,
• Planning,
• Code and interface design,
• Coding, Debugging and Testing,
• Documenting each activity.

11
And incorporates documentation

• Documentation is more than just a listing of the
  finished program.
• Documentation involves all of the following-
• Records of the analysis of the problem,
• The time resource plan,
• Technical and User documents,
• Records of all bugs and bug fixes,
• Records of test input and output.

12
And team work

• Different roles with a software development
  project
• People may join or leave a development team.
• Software engineering helps to co-ordinate the
  team so that they are on the same page
• How does it help?
• Lifecycles
• Automation of tasks

13
Software Development Lifecycles.

• Since the software crisis of the 70s, software
  developers have been looking for a solution
• to increase programmer productivity
• to increase the quality of software
• to decrease software production costs
• Why? Because industry (the users) were fed up
  waiting for software and because it was costly

14
Software DevelopmentLife Cycle(SDLC) - Classical

• Software Engineering has identified several
  classical life cycles with different
  complexities, different aims and different
  outcomes.
• Its up to you which one you choose
• I will describe some classic SDLCs

15
SDLC

• All life cycles describe a process that you use
  to produce software
• They are practical and are worth employing
• They all have common features - stages
• Systems Analysis and Design module involves a
  couple of stages in the software development life
  cycle

16
SDLC

• Examples include -
• Cyclic
• Waterfall/Cascade
• Evolutionary
• V

17
SDLC (cyclic)

• Cyclic features
• Easy to use
• Useful for bespoke/one off systems with no
  maintenance
• No definitive start or finish to the process
• Includes a recognition of management involvement
• Can be difficult to control

18
SDLC (cyclic)
Idea for a project or product
Contract for a Project
Concepts/ Feasibility
Requirements/ Specification
Management yes/no
Next version
Design and Code
Testing and Acceptance
Maintenance
19
SDLC (Waterfall)

• One of the most famous SDLCs - a waterfall
  because the stages of the lifecycle follow the
  premise of one stage following another
• Still shows a somewhat cyclic nature to software
  development.
• Shows the possibility of rework.
• Includes maintenance as a vital part of the
  cycle.
• No inbuilt control or management recognition (a
  weakness)

20
SDLC (waterfall)
System/Software Requirements
Analysis
Design
Code
Test
Release
Maintenance
21
SDLC (Evo)

• The Evolutionary life cycle is quite different
  from most other cycles.
• Tom Gilb is credited with this SDLC
• Its main principle is that of the surrounding
  environment and therefore the requirements
  continually change!/evolve
• Therefore an SDLC must reflect this position.

22
SDLC (Evo)

• Evo produces many small steps/ products towards
  an overall goal.
• It is VERY difficult to control.
• Many people argue that it is the ONLY way to
  achieve a quality product

23
SDLC (Evo)

• Evos guiding principles are -
• Deliver something to a real end-user
• Measure the added-value to the user in all
  critical dimensions
• Adjust both design and objectives based on
  observed realities.

24
SDLC (Evo)
Evolutionary Life Cycle.
initial objectives
revised course towards new objectives
heading towards initial objectives
useful delivery to user steps
changed objectives
25
SDLC (V)

• The V life cycle is an extension of the
  waterfall life cycle.
• It includes elements of Quality Assurance at
  every stage.
• Looks at the whole of the project
• No obvious management, but inbuilt control
  through QA.

26
SDLC (V)
Maintenance
Requirements Acceptance Test
Analysis System Test
High level Design
Integration Test
Low level Design
Module Test
Code Unit Test
V Life Cycle
27
Object-Oriented Methodology

• Object oriented technology is based on a few
  simple concepts that, when combined, produce
  significant improvements in software engineering.
• Unfortunately, the basic concepts of the
  technology often get lost in the excitement of
  advanced features and advantageous features. The
  basic characteristics of the OOM follow.

28
Object-Oriented Technology

• Characteristics of Object Oriented Technology
• Identity
• Classification
• Polymorphism
• Inheritance

29
Identify

• The term Object Oriented means that we organize
  the software as a collection of discrete objects.
• An object is a software package that contains the
  related data and the procedures. Although objects
  can be used for any purpose, they are most
  frequently used to represent real-world objects
  such as products, customers and sales orders.
• The basic idea is to define software objects that
  can interact with each other just as their real
  world counterparts do, modelling the way a system
  works and providing a natural foundation for
  building systems to manage that business.

30
Classification

• In principle, packaging data and procedures
  together makes perfect sense. In practice, it
  raises an awkward problem.
• Suppose we have many objects of the same general
  type- for example a thousand product objects,
  each of which could report its current price. Any
  data these objects contained could easily be
  unique for each object. Stock number, price,
  storage dimensions, stock on hand, reorder
  quantity, etc would differ from one product to
  the next.
• But the methods for dealing with these data might
  well be the same. Do we have to copy these
  methods and duplicate them in every object?
• No, this would be ridiculously inefficient. All
  object-oriented languages provide a simple way of
  capturing these commonalties in a single place.
  That place is called a class. The class acts as a
  kind of template for objects of similar nature.

31
Polymorphism

• Polymorphism is a Greek word meaning many
  forms.
• It is used to express the fact that the same
  message can be sent to many different objects and
  interpreted in different ways by each object.
• For example, we could send the message "move" to
  many different kinds of objects. They would all
  respond to the same message, but they might do so
  in very different ways.
• The move operation will behave differently for a
  window and differently for a chess piece.

32
Inheritance

• Inheritance is the sharing of attributes and
  operations among classes on a hierarchical
  relationship.
• A class can be defined as a generalized form and
  then it specialized in a subclass.
• Each subclass inherits all the properties of its
  superclass and adds its own properties in it.
• For example, a car and a bicycle are subclasses
  of a class road vehicle, as they both inherits
  all the qualities of a road vehicle and add their
  own properties to it.

33
Object Oriented Methodology

• By utilising object technology, a wide-range of
  applications can be engineered
• The aim is to produce a system that is robust,
  easy to maintain and structured (easy to
  understand hopefully!)
• OOM itself is a framework by which to create
  these systems.
• A variety of steps can be taken to achieve these
  aims. Youll be using some yourselves from next
  week
• Use Cases, Class Diagrams, Sequence diagrams etc

34
Summary

• Software Development life cycles describe the
  process used to produce software.
• Questions to always ask
• What does it achieve?
• What doesnt it achieve?
• How could you alter it to be better?

35
Summary - tips

• You must identify your life cycle.
• You must identify the requirements for your life
  cycle
• You should look at possible ways to improve it.
• Question - Should there be one life cycle for
  the team/project?
• What are the benefits and problems of such a
  suggestion?
• What are you going to do about it?

36
Summary - tips

• As we have discussed - some of the life cycles
  dont include recognition of project management
  and control
• Project management and control is CRUCIAL and you
  will find in industry/books reference being made
  to the Project Development Life Cycle(PDLC)
• The SDLC fits inside a PDLC - it is the life
  cycle for the software development part of the
  project(of course that may be the whole of the
  project)

37
What are you trying to become?

• A Software Engineer!
• SE includes both technical and non-technical
  elements, so software engineers must be able to
  communicate well, both orally and in writing.
• They must have a thorough knowledge of computer
  systems and must understand the importance of
  project management, user feedback, documentation
  and quality control.

38
The Future of Software Engineering

• SE still relevant in 2004 as in 1970
• Tools have changed
• CASE tools have had limited success - specialised
  tools tend to be used for each stage
• Modelling, Design, Testing, Optimisation etc.
• New set of challenges have appeared in the latter
  part of the 1990s - web development
• Requirements capture as important as ever for the
  success of a project
• Still evidence of projects failing however

39
Useful Info

• Take a look at some of the following websites
• http//en.wikipedia.org/wiki/Software_engineering
  
• http//www.fact-index.com/s/so/software_engineeri
  ng.html
• http//www.mtholyoke.edu/rzdalea/cs100/software_
  disasters/sd.htm