System and Software Engineering Overview AMS505 6'1 2001

1
System and Software Engineering OverviewAMS505
6.1 2001

• Major Greg Phillips
• Royal Military College of Canada
• Electrical and Computer Engineering
• greg.phillips_at_rmc.ca
• 1-613-541-6000 ext. 6190

2
System

• System (Websters Dictionary)
• an arrangement of organic things which forms an
  organic whole
• a set of organized principles which shows a
  logical plan linking the parts
• a method of classification or
• an established way of doing something
• Computer-based system (Pressman, ch. 10)
• a set or arrangement of elements that are
  organized to accomplish some pre-defined goal by
  processing information

3
Thinking about Systems
Unorganized complexity (aggregates) Treat
statistically
Randomness
Organized complexity (systems)
Gerald Weinberg, An Introduction to General
Systems Thinking, Wiley, 1975
Organized simplicity (machines) Treat
analytically
Complexity
4
Engineering

• the practical application of scientific knowledge
  using
• systematic approach
• management principles
• tools
• techniques, science, and mathematics
• to produce a product
• on time
• within budget
• meeting requirements
• to maintain, operate and retire systems
• with a responsibility to meet the needs of
  society as a whole

5
System Engineering

• The engineering of systems
• Two main functions of system engineering
• bounding the system (requirements engineering)
• allocation of functions (architectural design)
• Distinct from the engineering of subsystems
• hardware
• software
• procedures

6
Software Engineering

• The multi-person construction of multi-version
  software.
• David Lorge Parnas
• The application of sound scientific principles
  and well-understood technologies, processes and
  practices to the construction of significant
  software systems.
• Greg Phillips

7
Software is...

• infinitely malleable
• not subject to physical constraints
• essentially non linear
• currently without adequate mathematical models

8
Goals of Software Engineering

• correctness
• reliability
• robustness
• performance
• usability
• verifiability
• maintainability
• repairability
• evolvability

9
Goals of Software Engineering (II)

• reusability
• portability
• interoperability
• productivity
• timeliness
• visibility

10
Dimensions of Software Engineering

• Underlying science
• programming language semantics, complexity
  theory, computability theory, algorithms,
  parallelism, graph theory.
• System Engineering Fundamentals
• Key Technologies
• database, client-server, hypertext, programming
  models (imperative, structured, object-oriented,
  functional, logic, data-flow), components,
  real-time systems, artificial intelligence,
  neural networks, CASE.
• Processes and Practices
• system lifecycle models, requirements
  definition, system design, implementation,
  verification and validation, maintenance
• Management
• estimating, planning, metrics, organization and
  structure, team dynamics, milestone selection,
  contracting

11
The Human Dimension

• Software Engineering is, and likely always will
  be, a creative human activity.
• The key to success is getting sharp people
  actively engaged in the solution of your problem.

12
System Engineering Fundamentals

• Rigour and formality
• Separation of concerns
• Modularity
• Abstraction
• Anticipation of change
• Generality
• Incrementality

13
Rigour and Formality

• Rigour thoroughness, completeness, correctness
• Formality expression using purely formal
  symbols, suitable for manipulation by machine
• all software programs are strictly formal
• some designs have formal elements
• a few specifications have formal elements
• The formalist theory is that increased
  formality improves the level of rigour and the
  ultimate quality of the product

14
Separation of Concerns

• Structuring the problem so that each aspect can
  be dealt with separately
• This is the basis for dividing the project into
  specific work assignments, given to people with
  differing skills.

15
Modularity

• Supports separation of concerns
• Allows internal details of modules to be
  separated from module interactions
• Design can proceed top-down (decomposition) or
  bottom-up (composition)

high cohesion
16
Abstraction

• A process whereby we identify the important
  aspects of a phenomenon and ignore its details.
• A special case of separation of concerns in which
  we separate the the concern of important aspects
  from unimportant details.

17
Anticipation of Change

• The fundamental fact of software development
  Requirements Always Change
• If we take this into account when specifying,
  designing and constructing a software system, we
  can minimize the downstream costs of the changes
  we know will be coming.

18
Generality

• Every time you are asked to solve a problem, try
  to focus on the discovery of a more general
  problem that is hidden behind the problem at
  hand. It may happen that the generalized problem
  is not more complexit may even be simplerthan
  the original problem. Being more general, it is
  likely that the solution to the more generalized
  problem has more potential for being reused.

19
Incrementality

• Incrementality characterizes a process that
  proceeds in a stepwise fashion, in increments.
• Every large, functional software system was once
  a small, functional software system. Anonymous

20
Quality, Cost and Time

• You can have it good, fast, or cheap. Pick two.
• Judy Skinner, TRW

21
Key Activities in Software Production

• Requirements Definition
• What do we want to build?
• Design and Implementation
• How should we build it?
• Verification and Validation
• Does it do what we wanted?
• Maintenance
• How do we keep it useful as our needs change?

22
Life-cycle/Process Models

• A life-cycle or process model is an idealized
  image of the steps to be taken in producing a
  software system. It is a way of thinking about
  and organizing development.
• It shows the order and relationship of the key
  development activities.
• A process should answer the question what do I
  do next and should place the development in a
  well-understood context.

23
Waterfall
Feasibility study
Requirements analysis and specification
Design
Coding and module testing
Integration and system testing
Maintenance
24
Waterfall with Feedback
Feasibility study
Requirements analysis and specification
Design
Coding and module testing
Integration and system testing
Maintenance
25
The V Model
Feasibility study
Maintenance
Requirements analysis and specification
Acceptance test plan
Acceptance test
System Design
System integration test plan
System integration test
Sub-system integration test
Detailed Design
Sub-system integration test plan
Coding and module testing
26
Evolutionary Prototyping
Requirements gathering and refinement
Maintenance
27
Throw-away Prototyping
Requirements Analysis
Requirements gathering and refinement
Build prototype
Quick design
Customer evaluation of prototype
Refine prototype
28
Keep what works Prototyping
Requirements Analysis
Requirements gathering and refinement
Build prototype
Quick design
Customer evaluation of prototype
Refine prototype
29
Spiral (Boehm)
Planning
Risk analysis
Based on initial requirements
Based on customer reaction
Planning based on customer comments
Go/no go decision
Initial requirements gathering and project
planning
Initial prototype
Next-level prototype
Engineered system
Customer evaluation
Engineering
30
System and Software Engineering OverviewAMS505
6.1 2001

• Major Greg Phillips
• Royal Military College of Canada
• Electrical and Computer Engineering
• greg.phillips_at_rmc.ca
• 01-613-541-6000 ext. 6190