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.

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'.

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

• 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.

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

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

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

• not really a model, but a strategy for improving the s/w process irrespective of the model used.

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.

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

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?

1. the inputs coming into the program and
2. the outputs produced by the program.

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

1. Input/Output Specification
1. Input
2. Output
3. Exception Handling
2. Performance Specification
3. Delivery Schedule

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?

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?

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?

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.

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?

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

• 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. Problems with Structural Design (3) Several program design techniques has been developed in the past. Some well-known techniques are: data-flow design, object-oriented design, top-down design, and structured analysis and design. All of these techniques are based on divide and conquer approach. 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