This step is used to examine what the existing system does (also see dossier criterion A).  It is here that you will consider what the inputs, processes and outputs will be without having to worry about the computer system that may be used.

This step includes numerous facts that need to be considered and actions that need to be undertaken.  These include:

• interviews with potential users
• questionnaires
• studying existing documents / programs (use the internet and print for this - there is a lot of existing software out there)
• observing people using the existing system

Analysis usually starts with a description of the problem to be solved and an analysis of the data requirements.  It is important when considering the problem to make sure that it is feasible in the time allowed and the resources available (see also Step 2 for more).

This step is extremely important, especially when it comes to those dreadful IB Dossiers.  A precise and clear statement of what the problem is will alleviate confusion later, both for the programmer and the intended user.

In a real world situation, this problem should be properly communicated to the entire team working on the solution, and to the users of the program.  A feasibility report should be drawn up, reporting the costs as compared to the assumed benefits of the project.  The problem statement will also later allow for the program to be tested properly.

In terms of the dossier, this step is crucial in avoiding headaches later on.  Before proceeding past this point, the student must make sure that the task that they are to undertake is of a reasonable size, and that it actually serves some purpose (triviality is to be avoided at all costs).  It is also important to make sure that all IB requirements (see the Syllabus) are fulfilled through the algorithms and data structured to be used.

Projects that are too ambitious should be avoided for the dossier - these will only frustrate the student (and sometimes, all too late to be changed or revised).

This phase creates the objectives and limits of the development project.  It is important to note that this stage defines what the system will do, not how to do it.  There should be an analysis of the preliminary requirements that have been set forth.  Questions about cost need to be addressed.  Prototype programs can clarify the problem, as they can simulate the behavior of portions of the product that is desired.

In this phase, a plan is made concerning fundamental data types that are to be used, and from these, larger data structures can be formed.  The software parts of a solution need to be designed in detail and a common starting point is the module diagram, which breaks the problem down into smaller components (known as modules) in a process known as "top-down design".  Make sure to specify each module's purpose, assumptions, input and output.  Function specifications should include precise preconditions and post-conditions.  This process makes errors easier to locate.  It is often a good idea to do a dry-run algorithm or a trace.

This is the step where the programmer must define how the system will accomplish what it is supposed to do.  This phase includes data modeling (organization and documentation of data), process modeling (organization and documentation of the logic, policies, and procedures that are implemented by a system), interface design (specification of the dialog between the application user and the computer), and breaking a system's requirements into modules.

One approach to developing a program or a system of modules, libraries and programs is object-centered design, where you:

1. Identify the objects in the problem's specification and their types
2. Identify the operations needed to solve the problem
3. Arrange the operation in a sequence of steps, called an algorithm, which, when applied to the objects, will solve the problem

Sometimes you may be able to incorporate existing software components into your design.

In this phase, the programmer uses a high level language to construct a program using appropriate data types and constructs.  This stage would typically involve a team of programmers constructing the software from the modular design.  The software also needs to be carefully documented both for technical and non-technical users.

This is the phase where a working version of a system is created.  When a code for an application is created by a developer, many details are brought forth.  A combination of detailed design and coding works very well in creating an application that meets the needs and requirements of the users, but is cost-effective to build.

Here, the plan is implemented, producing a program and, for some problems, one or more libraries.  Source code should be correct, readable, and understandable.  Programs and subprograms should be well structured, as code may become very large and lengthy.  This will make it easier to maintain later on.

A modular solution is a hierarchy of sub-problems, which will correspond to modules in a program.  This is called "bottom-up implementation".  Another approach is "top-down implementation", where you implement a module before implementing some of its sub-modules.

In this phase, two types of tests are done.  Functional testing involves describing systematically what is supposed to happen when buttons are pressed on an event driven interface or menu choice are selected.  Test data should be developed at the design stage.  This data, which includes normal data, extreme data, and abnormal data, should be tested for.

Here, the program is tested and errors (bugs) are removed.  The detection and correction of errors is an important part of software development.  Check that documents and modules are correct, and check that these products match specification.  Try using trace tables and avoid "quick and dirty" patches.

A strategy that could be used is "bottom-up testing", which first tests the lowest level modules and then moves up the hierarchy of modules.

In this phase, the new program is installed into the new system in three possible ways:

1. Direct Implementation, which means at a certain point in time you stop using one system and start using another
2. Phased Implementation, which might be used where different parts are introduced at different times
3. Parallel Running, where you have both the new and the old system running at the same time

Installing an application involves bringing together various components.  This includes the executable application, a database, documentation, setup program, and various system files that support the application.  The final step of creating a deliver package is to test the package on a system configured as closely as possible to the user's computer system.

In this phase, once a system starts to run full time, bugs may be discovered while the program is being used.  These need fixing.  Ideas for improvement might come forth.  It is important to evaluate the performance of the new system.  New ideas need to be investigated and analyzed and so the cycle continues into a new loop.

This phase allows the developers to evaluate their initial application and modify it to better meet the needs of their customer.  Design, code, test and deliver an application's changes based on the customer's feedback.  Update and archive all analysis and design documentation to allow for better maintenance and enhancement of the application.  Finally, check that all business requirements outline in the Analysis phase have been met.

The program must be modified and updated as necessary to meet the user's needs and improve performance.  User-detected errors must be corrected and features should be added or features modified to suit the users better.