outline

Software Engineering (1)

• Suppose you are asked to design and then supervise the construction of an automobile, or a multistory office building, or perhaps a cathedral!!

Software Engineering (2)

• How can you estimate the cost in time, money, and other resources to complete the project?

Software Engineering (3)

• How can you divide the project into manageble pieces?

Software Engineering (4)

• How do can you assure that the pieces produced are compatible?

Software Engineering (5)

• How can those various working pieces communicate?

Software Engineering (6)

• How can you measure progress?

Software Engineering (7)

• How can you cope with the wide range of detail selection of door knobs, availability of blue glass, the strength of pillars, the design of duct work, etc?

Software Engineering (8)

• Development of large software involves similar or greater problems.

Software Engineering (9)

• Nov 9, 1079 (s/w eng with Java - Schach) The strategic air command had an alert scramble when the World-Wide Military Monitoring Command & Control System (WWMCCS) computer network reported the USSR had launched missiles towards USA.

Software Engineering (10)

• What actually happened was that a simulate attack was interpreted as the real thing! The exact deatails were not published, but it seems reasonable to ascribe the problem to a s/w fault.

Software Engineering (11)

• Either the system as a whole was not designed to differentiate between the simulation & reality, or the UI did not include the necessary checks for ensuring that users of the system would be able to distinguish fact from fiction.

Software Engineering (12)

• During the gulf war, a scud missile penetrated the patriot shield - killed 28 americans and wounded 98. The s/w for the Patriot missile contained a cumulative timing fault - made system inaccurate.

Software Engineering (13)

• Mechanical Engineering is like looking for a black cat in a lighten room.
• Chemical Engineering is like looking for a black cat in a dark room.

Software Engineering (14)

• Software Engineering is like looking for a black cat in a dark room in which there is no cat.
• System Engineering is like looking for a black cat in a dark room in which there is no cat and someone yells, "I got it!"

Software Engineering (15)

• Category	Typical Number of Programmers	Typical Duration	Product Size	Examples
  Trivial	1	1-2 weeks	< 500 lines	Student homework assignments
  Small	1-3	a few weeks or months	500-2,000 lines	Student team projects, advanced course assignments

Software Engineering (16)

• Category	Typical Number of Programmers	Typical Duration	Product Size	Examples
  Medium	2-5	a few months to one year	2,000-10,000	Research projects, simple production software such as assemblers, editors, loaders, recreational and educational software
  Large	5-25	1-3 years	10,000-100,000	Most current applications - word processors, speadsheets, operating systems for small computers, compilers

Software Engineering (17)

• Category	Typical Number of Programmers	Typical Duration	Product Size	Examples
  Very Large	25-100	3-5 years	100,000-1M	Large scale real-time operating systems, airline reservations systems
  Extremely Large	>100	>5 years	>1M	Advances military work, international tele- communications networks

Design Techniques

• Traditional engineering design techniques if applied in software design ...

Design Techniques 1. Tolerance

• In traditional engineering approach, the products are acceptible as long as they perform their task within certain bounds.

Design Techniques 1. Tolerance (2)

• A washing machine that cycles through its wash-rinse-spin cycle within a 2% tolerance of desired time is acceptable.

Design Techniques 1. Tolerance (3)

• A software prints cheques for the employees and it is correct 98% of the time. Is it acceptable?

Design Techniques 2. Metrics

• What metric (a quantitative measurement) can be used to measure the quality of software?

Design Techniques 2. Metrics (2)

• The quality of a mechanical device is often measured in terms of the mean time between failures, which depends on how the device endures wear and tear.

Design Techniques 2. Metrics (3)

• Software, in contrast, does not wear out.

Software Crisis

• 1. For every six new large-scale software systems that are put into operation, two others are cancelled.
  2. The average software development project overshoots its schedule by half.

Software Crisis (2)

• 3. Around three quarters of all large systems are 'operational-failures' - either way they do not work as intended or are not used at all!
  4. In 1968, NATO science committee invited 50top experts from academia and industry to find a solution to 'software crisis'.

Software Crisis (3)

• 5. Software Engineering:- The application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software.

Software Crisis (4)

• • The job of a s/w engineer is to deliver high-quality s/w products to agreed cast & schedule.
  • Need to plan
  • work according to the plan
  • strive to produce the highest quality products.

The Software Life Cycle (Waterfall Model) by Royce in 1970

• 1. Prior to implementation
  • Feasibility study
  • Program specification
  • Program design

The Software Life Cycle (Waterfall Model) by Royce in 1970 (2)

• 2. Implementation
  • Algorithm selection and analysis
  • Coding
  • Debugging

The Software Life Cycle (Waterfall Model) by Royce in 1970 (3)

• 3. Following Implementation
  • Testing, verification, benchmarking
  • Documentation
  • Maintenance

Other Models (Schach)

• Build-&-Fix
• Rapid Prototyping
• Incremental
• Spiral
• Capability Maturity Model (CMM- from SEI in CMU)
  • not really a model, but a strategy for improving the s/w process irrespective of the model used.

Problem Specification

• Problem specification, also known as requirements analysis, involves developing a clear, concise, and unambiguous statement of the exact problem to be solved.

Reasoning

• There are three reasons for the need to have a problem specification phase.
  1. real problems have many possible variations and outcomes - danger of overlooking.
  2. one may look into situations that are expected to occur and possibility of overlooking situations that that do not expect to occur.
  3. Specification are written in natural language which is usually unclear, imprecise, and ambiguous.

Example

• Solve the quadratic equation of the form,
• ax² + bx +c = using the quadratic formula,

•                     -b + sqrt(b2 - 4ac)
          roots = -----------------------
                                 2a

• 1.Possible variations and outcomes

• Case	Condition	Meaning
  1	(b2 - 4ac)> 0	two real roots present
  2	(b2 - 4ac) < 0	two imaginary roots present
  3	a = 0 , b not = 0	linear eqn. with single real root
  4	a = 0, b = 0	not a valid eqn. & no roots

Example (2)

• 2.Unexpected situation

• Case	Condition
  5	inputs larger than maximum representable size on the machine - will cause arithmetic overflow
  6	not enough number of input values were given
  7	input provided in the wrong format - e.g. 7.t

Example (3)

• 3.Imprecise user specificatopn of the problem
• Ex. Given a list of integers A₁, ..., A_n, and an interger value x, find the location i in the list such that A_i=x. If x does not occur anywhere in the list, find the location i of the value A_i that is closest to x.
• Are there any problems with this specification?

Example (4)

• Some ommissions and ambiguities in the above stated problem:
  1. What value should be returned if x appears more than once in the list?
  2. How should the word closest be interpreted in this context?
  3. What if the list is empty i.e. n=0?

The Specification Document

• The final product of the specification phase is a Specification Document. THis document clearly specifies two things:
  1. the inputs coming into the program and
  2. the outputs produced by the program.

•                            _________________
                             |                                |
             Input ---->|           program       | ----> Output
             (Input       |________________|      (output
        specification)                                       specification)

The Specification Document (2)

• The specification document now has the following format:
  1. Input/Output Specification
  1. Input
  2. Output
  3. Exception Handling
  2. Performance Specification
  3. Delivery Schedule

The Specification Document (3)

• 1. Input/Output Specifications
  1. Input Specifications
  1. What are the inputs to the program and what does each value represent?
  2. How many inputs and what order they appear?
  3. What is the formats?

The Specification Document (4)

• 4. What are the units?
  5. From what inputs device will the inputs come?
  6. What are the bounds of the inputs?
  7. When to terminate reading inputs?

The Specification Document (5)

• 2. Output Specifications
     1. What are the required outputs?
     2. What should be the accuracy?
     3. What are the units?
     4. What formats are needed (title, spacing, etc.)?
     5. To what device the output should be send?

The Specification Document (6)

• 3. Exception Handling
     1. If input falls outside the bounds.
     2. If insufficient or excessive inputs.
     3. If improper format occurs.
     4. If input leads to illegal operation.

The Specification Document (7)

• 2. Performance Specifications
     1. What is the acceptable time to produce a particular set of result?
     2. What should be the memory requirement to run the program?
     3. What are the specific operating environment in which the program should run?

The Specification Document (8)

• 3. Delivery Schedule
     1. What is the time frame to deliver the final product and supporting documentation?

Exercise Problem #1

• Develop a software that will calculate and print bills for the city power company. The rates vary depending whether the use is residential, commercial, or industrial. A code "R" means residential use, a code of "C" means commerial, and code of "I" means industial use. Any code should be treated as an error. The rates are computed as:

Exercise Problem #1 (2)

• R: $6.00 plus $0.052 per kwh used
• C: $60.00 for the first 1000 kwh and $0.045 for each additional kwh
• I: Rate varies depending on time of usage.
  • Peak hours: $76.00 for first 1000 kwh and $0.065 for each additional kwh
  • Off-peak hours: $40.00 for first 1000 kwh and $0.028 for each additional kwh

  Exercise Problem #1 (3)

  • The software should prompt the user to enter an integer account number, the code (type char), and the kwh used. If the user code is I, the program should also prompt to see how many kwh for peak hours and for non-peak hours.
    1. List all the omissions and ambiguities in the problem if there are any.
    2. Prepare a Specification Document for the above problem after fixing omissions and ambiguities.

  Exercise Problem #2

  • For the above problem, create a "Program Development Tree' and prepare a "Program Design Document". This document should specify all the modules necessary for the above problem.

  Phase II: Program Design

  • The problem specification phase provided a clear, precise, and unambiguous documentation of the given problem.
  • If the problem that needs to be solved is small, say 10-50 lines of code, the next logical step is to start writing the code.
  • However for all real-world problems the next important phase is called program design which precedes actual coding or implementation.

  Phase II: Program Design

  • How do we approach the task of writing a software that contains 100,000 lines of code? A single program of 100,000 lines of code would be a clear disaster!!
    • Think how one could debug, test, and modify such a huge program?
  • One way to solve such a massive problem is to use divide and conquer or sub-goal approach.

  Structural Analysis and Design

  • Main model of software design since '70s.
  • A complex problem is subdivided into simpler pieces called modules
  • Based on dividing the original problem into sub-problems.
  • Top-down methodology, allows to keep the big-picture in mind.

  Problems with Structural Design

  • Focus on modules causes data structure access to be diffuse throughout the code.
    • Difficult to understand the impacts of change.
  • Software is not very robust to change
    • Seemingly simple modules breaks on simple changes.
    • Over time, the program becomes unmodifiable.

  Problems with Structural Design (2)

  • The divide and conquer approach divides (decomposes) a large problem into small problems that are easily manageable.
    
  • Ex: Our University Structure
    
  • In software development, we call each sub-problems a module or sub-programs. Each module will perform one specific task and may have 40-50 lines of code.

  Top-Down Design

  • The strategy here is to start from high-level goals and progress towards low-level solution methods.
  • For example, a given problem P is divided into three simpler sub-problems, P₁, P₂, P₃. This kind of a decomposition can be represented using a program development tree.

  The program development tree

  •