WELCOME TO SENG 411

1
WELCOME TO SENG 411!

• KEYWORD
• TEAM WORK!
• http//sern.ucalgary.ca/courses/cpsc/451/F00/cpsc4
  51.htmlRTFToC3

2
MOTTO

• IS NOT THE LOAD THAT BRINGS YOU DOWN IS THE WAY
  YOU CARRY IT !
• LOOK AT THE BRIGHT SIDE!
• CELEBRATE YOUR TEAM PARTNERS (and encourage!)
• RESPECT THE DIFFERENCES
• EXTEND YOUR BOUNDAIRES!

3
PURPOSE

• To provide an overview of techniques and
  methodologies for applied software engineering. 
• ? WHAT IS SOFTWARE ENGINEERING
• ?WHY DO WE NEED IT

4
SOFTWARE ENGINEERING

• The Science (proof via scientific method) and Art
  (creativity) of Designing complex software
  systems
• Design - disciplined approach to invent a
  solution for some problem - the path from
  requirements to implementation

5
DISCIPLINE

• NEEDED TO DEAL WITH COMPLEXITY
• TOOL FOR MANAGING CHAOS (to order and clarify)
• RULES
• Design - Creates a simple and clear internal
  structure (architecture) by balancing competing
  requirements

6
EXAMPLE

• Date/ Artifact/ Marks ( of project)
• 18 Sept /C1 Informal Specification of
  Requirements/ 2 
• 25 Sept /S1 Functional Spec. and Mgmt Plan /10 

7
WHY?

• THE HORROR STORIES
• A hospital minicomputer, monitoring a patient
  recovering from surgery, fails to alert hospital
  staff that the patient is having a stroke. The
  patient dies. -- Washington Post 

8
WHAT DO WE NEED?

• Problems stem from an unrealistic view of what it
  takes to construct the software to perform these
  tasks.
• THIS CALLS FOR 
• better understand the development process 
• learn how to estimate trade off time, manpower,
  dollars 
• estimate and measure the quality, reliability,
  and cost of the end product.

9
Software Life Cycle

• Waterfall Model

10
PROBLEMS

• The rigid sequential flow of the model is rarely
  encountered in real life. Iteration can occur
  causing the sequence of steps to become muddled. 
  
• It is often difficult for the customer to provide
  a detailed specification of what is required
  early in the process. Yet this model requires a
  definite specification as a necessary building
  block for subsequent steps. 
• Much time can pass before any operational
  elements of the system are available for customer
  evaluation. If a major error in implementation is
  made, it may not be uncovered until much later. 

11
PROTOTYPING
12
APPLICABILITY

• In object oriented programming a library of
  reusable objects (data structures and associated
  procedures) the software engineer can rapidly
  create prototypes and production programs. 
• Prototyping is applicable only to a limited class
  of problems. In general, a prototype is valuable
  when heavy human-machine interaction occurs, when
  complex output is to be produced or when new or
  untested algorithms are to be applied. It is far
  less beneficial for large, batch-oriented
  processing or embedded process control
  applications

13
BENEFITS

• a working model is provided to the customer/user
  early in the process, enabling early assessment
  and bolstering confidence,
• the developer gains experience and insight by
  building the model, thereby resulting in a more
  solid implementation of "the real thing"
• the prototype serves to clarify otherwise vague
  requirements, reducing ambiguity and improving
  communication between developer and user.

14
DRAWBACKS

• The user sees what appears to be a fully working
  system (in actuality, it is a partially working
  model) and believes that the prototype (a model)
  can be easily transformed into a production
  system. This is rarely the case. Yet many users
  have pressured developers into releasing
  prototypes for production use that have been
  unreliable, and worse, virtually unmaintainable.
• The developer often makes technical compromises
  to build a "quick and dirty" model. Sometimes
  these compromises are propagated into the
  production system, resulting in implementation
  and maintenance problems.

15
Project Phases for the Development of Large
Systems

• Initial conception
• Requirements analysis
• Specification
• Initial design
• Verification and test of design
• Redesign
• Prototype manufacturing
• Assembly and system-integration tests
• Acceptance tests (validation of design)
• Production (if several systems are required)
• Field (operational) trial and debugging
• Field maintenance
• Design and installation of added features
• System discard (death of system) or complete
  system redesign.

16
Boehms Estimates

• 40 of effort on analysis and design
• 20 on coding and auditing (handchecking)
• 40 on testing and correcting bugs.
• (Documentation was not included, estimated at
  extra 10.)

17
Cost of Changes

• Testing becomes more complex and costly
• Documentation of changes becomes more widespread
  and costly
• Communication of problems and changes involves
  many people
• Repeating of previous tests (regression testing)
  becomes costly
• Once operation is begun, the development team is
  disbanded and reassigned.
•