This component of the course is your first introduction to software engineering.  Software engineering is the study of developing programs, usually for large commercial applications but is not restricted to large programs.  The subject includes exciting topics like:

• Software management
• Software design
• Software verification
• Software usability
• Software metric

Programming Process:
Consider how we solve problems.  My education and experience is very diverse but I have found that I solve problems in the same way.  My technique is:

1. Analyze the problem
I have found that the better I know the problem the easier it is to solve.  It is almost like the problem disappears.  This is also the time I do background study is the subject.  If I am fixing something I will perform diagnostics.  If I making something for someone else I make clear what they want.
2. Design a solution
The more time I spend designing the solution the easier it is to implement.  If the solution has visual component or is some hardware I make drawings.  If I am making it for someone else I share the drawings with them.
3. Implement the solution
I have found that if I have done a good job analyzing and designing then implementing the solution is easy, even automatic.  Sometimes I feel like I am getting stuck in the analysis and design stage; I can get unstuck if I push ahead to the implementation stage realizing that I will most probably have to repeat the whole process.  Then implementation becomes part of the analysis.  We can learn a lot about a problem by trying to solve it.
4. Check the solution
You should never forget this part of the process.  Even if I am making a painting for myself I will look at the painting asking; "does it look like what I want, how could have done it better?"   I certainly do not want to give the product/solution to the customer without making sure it is correct. Finally I give the product or solution to the customer asking for his evaluation.  Hopefully I get paid.

The Waterfall Process:

1. Analysis
The programmer leans about the problem domain, and corresponds with the end user to make sure that he correctly understands the problem.  As much as possible a program specification is written. The specification concentrates on what the program will do not how the program will work.
2. Design
Considerable time is spent at this stage.  The overall program design (called the system architecture) is established.  Depending on the program domain different design tools are available, for example I have found for a graphical user interface (gui) drawings of the windows is very helpful, and for complicated objected orientated programs (oop) I have found diagramming the object hierarchy and interaction very clarifying.
3. Code
Hopefully this is straight forward. I have found that including program verification and documentation during the coding process makes life much easier.
4. Test
The most important phase of programming.  Some programming process incorporate testing at the beginning; during the analysis talking with the customer about how to test the product, during the design including test design, and during the coding adding test codes.  Always the customer does the final testing.  Program maintenance  is included in this phase.

Incremental Process:

The incremental process can be implemented by iterating on the waterfall process.  This gets program examples to the customer early.  If the software company has enough programmers several increments may be developing simultaneously.  The incremental process can be used to add features.  In my research I develop image processing techniques.  I constantly employ the incremental process adding new algorithms and verifying the algorithms and programs before reusing.  OOP is particularly adaptive to the incremental process.  Classes can be added to the program,  classes can be implemented differently by inheritance, features can be added to classes also by inheritance.

Management:
The management aspects that we will discuss is the relationship between the freelance programmer and customer.  A team project can explore the aspects of managing a team.  The important aspects of programmer-client relationship are similar to all interrelationships:

• Respect the client
The client is going to pay you and is ultimately in control of the relationship.  If you act disrespectful to the client you can be assured that it will cost you.  Never act like the client does not know what he is doing.  Frequently the client is called the "domain expert."  He is the expert in respect to solve the problem.
• Listen to the client
You cannot write a good program for the client if you do not listen to him.  Get the client talking by asking him questions about his problem.  Generally the client does not care how the program is written, so do not bore him with programming details.
• Communicate
Your best means of communicating with the client is to give him results.  Results do not always have to be complete programs. Results can include documents, drawings, and mock-up programs.  The client then has something tangible to respond to.
• Customer is always right
Remember he is domain expert. You can suggest to the clients improvements but he makes the decisions.

1. Initial contact
Generally the form of communication is very informal; meaning email, phone conversation and causal meetings.  The goal of the programmer is to make sure that the solution to the problem is a program and that you can write the program.  Suggest a second informal meeting to learn more about the problem. Do not forget to thank him.
2. Learning the problem
Still an informal meeting, but now you keep more detail notes.  Your goal is to learn his problem well enough to get idea of what the final product looks like, not how the program is written.
3. Initial response
Now the relationship becomes more formal and the programmer gives the client tangibles which include:
• Description of Problem
This a written document describing the problem. The customer can check to make sure that you and he are understanding each other.
• What you will produce and provide
This can include an example use-case, a written description of  an example end-user using the program.  Also drawings of the gui help clarify the end result and the example use-case.
This prepares the client and you for the contract.
4. Mock-up Program
Especially if the program has a gui, generate a gui that does nothing but write messages.  The client will get an idea of the program, and respond to you by making suggestions.  Early versions assure the client that you are working.
5. Hopeful Final Program
You may give the client many version until you are both satisfied.
6. Final Program and the continued relationship
Hopefully both you and client can agree on the final version, but he will find bugs if he uses the program much.  It is to your best advantage to fix these bugs.  The bugs do represent errors in the code, at least as far as the client is concerned.  A good continuous client-programmer relationship will ensure future work.