implementation

One of the 8 steps in the waterfall (Linear Sequential) software process model. Implementation takes place after the design phase and before the integration phase.

Once the architecture of the system has been developed, broken down into modules, and a detailed design has been developed for each of these subsystems, then this phase can begin. It consists of writing the actual source code and performing tests on this code.

After implementation is finished, it is then time for integration, in which all of the components are combined and tested together as a single system.

To implement something is to do it as opposed to planning it or agreeing to do it.
E.g. UN resolution 242 was swiftly passed, however the implementation is proving difficult.

The root word is implement, so implementation is where the implement is applied to the surface.

 

In computer programming project methodologies, implementation refers to the phase of actual coding as divorced from requirements gathering and design which come before it; and integration, testing, rollout and maintenance which come after it.
E.g We have implemented according to specification.

However in reality is is hard to draw such sharp distinctions.

Writing code can be a form of design, of expressing a design and testing its doablity, so implementation is favoured by some programmers as a method of design. Any design that has not been put to the test of coding is not proven to be sound - issues often come up during coding that were not forseen, so design without coding is problematic.

Also, code that is not integrated and tested is not proven to be suitably robust, and thus some integration and testing will occur during implementation. And some more coding (i.e. implementation) will occur as a result of testing.

One the most interesting new methodologies, Extreme programming denies that implementation can or should be partitioned off as a separate activity from testing and design. Open Source development on some of the largest and most successful projects such as Mozilla and Linux proceeds without a clearly delineated "implementation" phase that is without design or integration.

Excessively linear software development models are the sign of excessively hidebound organisations. Avoid them if you can. Worst are those companies in which design is completely divorced from implementation, designers never stoop to implement and implementers are never allowed to design.

 

When there is a standard, an implementation can refer to a particular instance of that standard, which is functionally the same (or mostly the same) as others, but which of course will have it's own strengths, quirks and weaknesses.
e.g. BSD's implementation of TCP/IP is great or Without the fancy graphics, Diablo is just a reimplementation of nethack.

 

In some object-oriented programming languages there is a separation between interface and implementation parts of classes. Even when there is not, a particular section of code may be referred to as "interface code" or "implementation code".

Implementation

The fifth stage of the classical six stage systems analysis model.

tr.v. im·ple·ment·ed, im·ple·ment·ing, im·ple·ments 

1. To put into practical effect; carry out: implement the new procedures.
2. To supply with implements.

http://dictionary.reference.com/search?q=Implementation

The “GO” button of the systems analysis lifecycle, the implementation of the plan drawn up and codified in the design stage, implementation is the fulfilment of the efforts so far made and (given our analysts are any good) the realisation of the dreams and hopes of workers and managers alike.

Now any code required will be written, hardware assembled and training manuals will be assembled.  All the choices have already been made and any graphics will have already been produced.  This stage is so called because it is the implementation of the designs made in the previous stage.

Every team member will now be working on his or her assigned task.  It is not necessary for any team member to know what the whole will be like if the planning of the design stage has been done fully and skilfully. However one should consider the example of Microsoft who are renown for not telling programmers what they are programming and the result – software that requires years of fixes and often simply doesn’t work.  It is important to remember that while it is possible to do much in theory - in practice things are never quite the same.  While engaged in the implementation of a project plan never forget that human beings are involved.  This may sound trite but in actual fact this is a vital distinction for the successful market leader to recognise.

After the alpha testing of the system, which takes place “in house”, there are a couple of implementation options:

1. Full and sudden replacement
2. Gradual phasing in of new system (usually with concurrent operation of systems)

Option two is the only one that becomes feasible as the size of the system increases; this is not necessarily a good thing.  A popular implementation of the second implementation option is department by department (or room by room) full training followed by replacement. 

Sometimes the beta testing forms part of the final implementation of the system but this is not always possible.  Even if it is there is the danger of early versions remaining in the system creating security holes and even endangering the data.  The systems analyst must be aware of these dangers and take appropriate steps to avoid them.

However one of the major problem groups that should have been dealt with during the design stage are the problems associated with a gradual phasing in of a system and these can easily be over looked:

• Incompatibility between the two systems
• Data conversion time-scale
• Data input requirements
• Interruption to work often running over many weeks
• Limitation of ability of users to function normally

Implementation can be one of the most volatile and disruptive processes the user / client can encounter.  If done poorly then the interruption caused by this stage can be many orders of magnitude greater than the in-depth study.

The planning carried out during the design stage should have anticipated this and this stage should pass without a hitch.  However this is never going to be the case in a real life scenario so as this stage prepares to be started the analysts should have clearly specified their plans and systems in place to minimise the negative effects of implementation.

Part of this planning requires liaisons with management to discuss the planned timescale of implementation.  It is often noted that most of the loss control during this stage depends solely on the clients themselves. 

Points to be considered during this process are:

• What will works be doing while normal work is impossible due to interruptions?
• How customer requests will be dealt with?
• How will an image of “business as usual” while this is going on?
• What temporary measures will need to be implanted first?

 

 

---

After a few messages back and forth I feel it necessary to point out that the implementation options come in a number of different flavours but they are basicly one or the other.

---

Classical Model of Systems analysis.  AKA the System Life Cycle

1. Project Selection
2. Feasibility Study
3. Definition
4. Design
5. implementation
6. Evaluation