1. Algorithms II
Software Development
Life-Cycle

2. Problem Solving
Problem solving is the process of transforming the description of a problem into the solution of that problem by using our knowledge of the problem domain and by relying on our ability to select and use appropriate problem-solving strategies, techniques, and tools.

3. Problem Solving
Problem Solving
Procedure
Environment
Problem
Solution

4. Problem Solving Solution Input Output
A solution is anything that connects the input to the output.

5. Why Use Computers Use a computer to solve a problem if:
It has extensive input.
It has extensive output.
Its method of solution is too complicated to implement manually.
If done manually, it takes an excessively long time to solve.
We expect to use the same method often.

6. Software Development Life Cycle
Requirements specification
Analysis
Design
Implementation
Testing and verification
Documentation
Maintenance and Enhancement

7. Sample Problem: QuikTax
Customer: QuikTax, a local tax preparation service.
Task: “Develop a program to calculate Federal Tax from the Federal Tax Schedules for the 1999 tax year.”

8. Requirements Specifications
“If you don’t know where you’re going, then any road will take you there.
Critical Questions:
What is the current situation?
What is the desired situation?
What constraints limit possible solutions?
What special conditions must be met?
Goal: complete understanding of problem space and solution space.

9. QuikTax Requirements Inputs: Output: Constraints: ?
Taxpayer income (wages, interest, etc)
Schedule data.
Output:
Tax payment (on form? backup data?)
Constraints: ?
Special Conditions:
April 15?
Refunds?
Earned Income Credit?

10. Analysis In this phase we identify: Specific inputs and their forms
Specific outputs expected from and their forms
Special Constraints
Assumptions
Formulas

11. Inputs What items must be provided to be able to get a solution?
Taxable income $0.00 to $1,000,000, (+?)
Filing status: S/M, Head of household
Number of dependents: ?
Dividends, interest, capital gains?
Deductions, adjustments, … ?

12. Output Intermediate results Final results All calculations?
Completed forms:
1040
Schedules A,B,C,..?
Estimated Tax
Working papers and justification?

13. Constraints What are the limits on the data?
Income can not be negative.
Number of dependents usually one or more (may be zero). Is there a maximum?
Filing status must be one of a set of values

14. Assumptions
Problem deals in $US
What’s implied by the Requirements?

15. Formulas For income tax, it is the tax tables and accessory formulas.
For determining the area, it is length x width
For grades, it is:
>90.0% A
80.0% % B
70.0% % C
60.0% % D
>60.0% F

16. Design
Develop a series of steps with a logical order which, when applied to the input would produce the specified output. (does this sound like an ALGORITHM?)
This phase is when you think about how to solve the problem!!
This phase can take forty per cent of the effort.

17. Design for Maintenance and Enhancement
Identify and separate critical data:
Use names: RATE = 0.18
use TAX = net_income * RATE
not TAX = net_income * 0.18
Functional Decomposition: Identify and group critical functions
Taxpayer ID functions
Dependent and deduction calculations
Special Forms
Final Tax obligation
Many valid alternative decompositions.

18. “Design at the Keyboard” is not design.
Implementation
This is the phase where the design is transformed into code.
This is the only portion of the process that is computer and compiler specific.
This should be approximately ten per cent of the effort.
“Design at the Keyboard” is not design.

19. Implementation Errors
Design errors
Design can’t be implemented
Matrices too large, not enough precision,…
Syntax errors
Incorrect language forms
Run-time errors
Arithmetic errors
Unanticipated input

20. Testing and Verification
Once the code is developed:
Demonstrate the program produces correct results.
Demonstrate that the program that was built solves the problem that was described in the requirements specification.
Manually solve the problem with a data set, then compare that to the program’s output
Construct an alternate computer solution for special easy-to-implement cases.

21. Documentation should be a complete explanation of code as implemented.
Consists of
A concise requirements specification
Description of inputs, outputs, constraints, and formulas used
Pseudocode or flowchart of the algorithm
Source code listing
Hard copy of a sample of data and the output
User’s guide explaining how to use the program
Documentation should be a complete explanation of code as implemented.

22. Maintenance and Enhancement
Environments change, so programs must be changed
Tax tables change
Name of organization changes
Users want (or need) the program to do more
New tax credits
Elimination of old tax credits.

23. Design for Maintenance and Enhancement
Identify and separate critical data:
Use names: RATE = 0.18
use TAX = net_income * RATE
not TAX = net_income * 0.18
Changes are easier/Less chance of error
Data is in one place/one change changes all
Easier to understand.
RATE -vs- 0.18

24. Design for Maintenance and Enhancement
Functional Decomposition: Identify and group critical functions
Taxpayer ID functions
Dependent and deduction calculations
Special Forms
Final Tax obligation
Easier to find and identify code to change.
Effects limited to local area.