Program Design Methodology

"A company must understand that the product is everything that is required to put the software into the box. " -- Steve McGuire

Program Design Methodology Review

Why Plan?

Group projects without a plan will not work.
If you have not figured out the design before you begin coding, you may paint yourself into a corner and have to start over.
You will save time by planning.
You can verify that the algorithm works before coding.
The plan is your "blueprint" for software construction.

How do I Design an Algorithm?

Good question. There is no real answer to this question that works in all cases.
Algorithm design is the creative part of programming--a very human endeavor.
Computer programming is an art.
Elegant solutions are the simplest, but not all problems can be solved elegantly
Experience helps--patterns of problems and solutions emerge over time.

Some Help

Make sure that specifications are complete and make sense. Do you understand the problem?
Determine what the program is supposed to output.
What errors might occur while the program is running?
How should the program end?
Get answers to questions about the specifications before writing any code.

More Help

Break the problem into subproblems
For each subproblem
- write a concise problem statement to be sure you understand
- find an existing algorithm (if there is one), or create a new one
- design the data structures needed
- write out the steps (algorithm) for solving the subproblem
Create the code to implement your solution
- code and debug each function separately
- this is called procedural abstraction
- test all functions together

Implementation

Using the plan you developed, begin writing code.
Document as you code, preferrably with automatic documentation generators (e.g. JavaDoc or Doxygen)
Place detailed comments at the beginning of the program/module explaining the purpose of the program/module
Make comments for each function and use comments for unusual logic

Testing

Testing can use about half the time for development of a system.
Test modules independently.
- drivers to test modules
- stubs to test modules for which functions have not been developed
- test cases that exercise all logical possibilities. Test normal and borderline cases.

Robustness

How will the program react to invalid data?
Should the program crash?
User-friendly error messages. Are compiler messages user-friendly?
How robust a program needs to be depends on the specifications and the user.

System Testing

Testing modules alone is not enough.
The whole system with all modules included needs to be tested.
Testing by end-users should be done since they are the ones who must ultimately accept the system. (Beta testers)
Systems that do not get the acceptance of the end users will fail even if well written.

Debugging

When you encounter errors:
- Think!
- Random changes only make the problem worse.
- Use debugging tools.
- Fixing one error may cause another error (or more.) Retest with the same tests as before.
- Keep the test cases for future use.

Application Programming Interface (API)

Often (redundantly) referred to as "API Programming".
Clear distinction between client and services.
API programming can be challenging since you are essentially creating "tools" for other developers. (Although, the other developer can be yourself.)
The client of your services are typically other developers (as opposed to applications you write, whose clients are generally end-users).
Some of the software development processes to follow:
- Specification - This will be done by the client.
- Design and Implementation - This will be done by both client and services. The client will specify the interface, and you will code the implementation. Since we want to implement specific data structures and algorithms, you will also be given certain "implementation guidelines" as well.
- Verification and Validation - Testing. This is done by the services. Of course, the client (me) will also run validation tests in order to grade your implementation.
This is the kind of programming that we will do in CS 280.
I will play the part of the "client" and you will be the "services".

Review of The Software Development Cycle

Up until now, how have you approached software development? Most projects deal with these aspects:

User Requirement Analysis
Functional Specifications
Design
Implementation
Testing
Deployment
Maintenance

Which tasks are done by junior programmers? Senior programmers?
Which task takes the most amount of time/resources? Least amount?
Who does what? (Specifications, design, coding, testing, documentation, etc.)

An excellent source of information for professional programmers is Steve McConnell's book Code Complete 2nd Edition, A Practical Handbook of Software Construction. This book deals primarily with the implementation (construction) phase of software development. Steve has a website that lists some of his books. It's highly rated on a thread on stackoverflow.

Methodologies and the Software Life Cycle (Two Examples)

Waterfall Life-Cycle Iterative Life-Cycle

The shaded area indicates the phases related to programming.
Source: Code Complete (McConnell 1993).

The waterfall model was one of the first processes in software engineering.
The waterfall methodology was replaced by a more iterative (and real-world) model, sometimes referred to as an evolutionary model. (The specification is developed along with the implementation.)
Component-based development takes object-oriented programming to the next level. Very high-level of reuse. (Borland's VCL framework is an excellent example.)
A relatively new and popular method is Extreme Programming or XP, which is a form of Agile Software Development.
Test Driven Development is a process whereby you create the test cases before you implement the functionality. Martin Fowler (of Refactoring fame) talks about it here.
In some way, all of the assignments in CS 280 will require TDD.
Most non-trivial programming projects use a combination of these methods, depending on the complexity of the development, number of developers, experience, etc.

Project Size vs. Devlopment Time

Source: Evaluating Software Engineering Technologies (Card)

Smaller Projects:

As a software project increases in size, the kinds and proportions of activities can vary dramatically.
The time spent on different kinds of development activities changes as the size of the project changes.
In smaller projects, the construction phase dominates the activity with design and testing receiving minimal attention. Smaller projects:
- are usually less complex
- perform very few functions
- are not influenced by outside sources.
Small projects, typically a single program, are designed, developed, and used by one (often the same) person.

Larger Projects

Larger projects are complicated by outside influences and, therefore, require greater attention to non-construction activities, such as specifications and testing.
These programs are developed by a team of people and are usually pieces to another larger program.
The time spent on communication alone is one factor that is non-existent in a small, single program project.
The larger program, a complete product, will most likely be used by people other than the developers.

Systems

Systems are larger than individual projects.

These super-projects are composed of many programs and/or products requiring a high degree of integration.

These systems are designed by several teams of developers, some who are physically located in different geographic regions.

There is tremendous effort expended in the areas of specification and architecture to ensure that all parties have a very clear picture of what their responsibilities include. It should be realized, that large, complex software is developed in groups and that these groups (or teams) are subject to the same problems that afflict all group interactions, regardless of the issues at hand. In his classic book The Mythical Man-Month, Frederick Brooks performs an audit on the construction of the Tower of Babel and why it failed. He notes that the most significant cause was the lack of communication amongst the builders (Brooks 1995).

Complexity of Communications within Groups

Source: Dynamics of Software Development (McCarthy 1995).

Project Type is a Factor

The project type influences the development process, not just the size of the project.
The type of software produced also determines the distribution of the development time
For example, an operating system development requires that the testing phase account for 50% of the total development time. This may seem intuitive given the fact that all software that runs on a computer must run on top of an operating system. If the operating system has even minor flaws, the system as a whole can be rendered useless.

Life Cycle Cost Distribution (Numbers in Percent)

System Type Requirements/Design Implementation Testing

Command and control systems 46 20 34

Space program systems 34 20 46

Operating systems 33 17 50

Scientific systems 44 26 30

Business systems 44 28 28

Your Game Project ?? ?? ??

Software Engineering, 4/e (Sommerville)

System Type	Requirements/Design	Implementation	Testing
Command and control systems	46	20	34
Space program systems	34	20	46
Operating systems	33	17	50
Scientific systems	44	26	30
Business systems	44	28	28
Your Game Project	??	??	??

Characteristics of a Good Program

Correct
- Does what the user asks it to do
- It really doesn't matter how fast or efficient a program is if it doesn't do what the user needs.
- Programs must not solve the wrong problem.
Robust
- Programs need to handle all input, both the expected and the unexpected.
- This is usually due to bad programming logic or bad data.
- If the user provides bad data, it's still the programmer's fault if the program crashes.
- Except for physical problems with the hardware, program crashes are almost always the fault of the programmer.
Portable
- Many times this is referred to as cross-platform, meaning that the program can run on different computers.
- This generally needs to be factored into the implementation at the outset.
- Trying to "port" programs that were never intended to run on another system is very difficult.
- Many times the developers will simply "start over" rather than to port code.
Maintainable
- Some programs can last for many years.
- Because "any software worth using is worth enhancing",programs are in constant development.
- Most code is in maintenance mode.
- This means that 5 minutes after you write a brand new function, it is now just code that needs to be maintained for the rest of its life.
- Code is only "new" until the ink dries.
Readable
- Many people feel this is the most important aspect of a good program.
- If a program is very readable, it's likely that the other characteristics will be much easier to attain.
- C (and thus, C++) has been termed a "write-only" language because it allows programmers to write completely unintelligible code. (At least to the poor maintenance programmer who comes after.)
Efficient
- This relates to resources (such as memory or CPU time.)
- The goal is for programs to use the least amount of memory, disk storage, CPU cycles, etc. to get the job done.
- Unfortunately, all too often the other characteristics of a good program are traded for the promise of a very fast and efficient program.
- In this class, we are going to learn to choose our battles.

Summary

The ultimate reason for using strategies such as these is to increase a company's profit.
Although there is an initial investment in these methods, the return on the investment can pay for itself after the first project is shipped on-time, within budget, and bug-free.
There are many other side effects, but they all result in profits one way or another.
In no particular order, these are some reasons to approach software development in this way:
- Able to better diagnose the problem resulting in a more correct solution
- Easier to estimate time and cost factors when scheduling or bidding on projects
- Products are more likely to be delivered on schedule and within budget
- Easier to maintain and enhance the product over it's life span
- Customer satisfaction which will lead to a better reputation for the company
- Developers are more likely to remain in a position where they can produce high-quality products
- Profits (money). For better or worse, this is what all commercial software boils down to.