Unified Process

Unified Process is one of the most important software industry patterns as of late. This software process was spearheaded by 3 experts in object-oriented analysis in the 1990's: Jacbson, Booch and Rumbaugh). This is the first ever model to be designed after the UML notation. It started to find wide acceptation as a best practice for market ROI. Among the UP features one could quote:
-Clear and precise instructions;
-promotes accountability;
-activities that stress out input and output artefacts
-defines the dependency relationships among activities;
-comprises a well understood life cycle model;
-emphasises the use of the right procedures with the available resources;
-strong correlation with UML.

As a framework, UP is easily adapted to a variety of processes, encompassing the needs of different businesses. Its main features are:

1- Use case-driven- This is process understood from the user's viewpoint, without touching on implementation details. This means a comprehensive collection of all functional requirements that the proposed system has to include. Non-functional requirements might be noted along matching use cases, while extra requirements are kept in a different document.

2- Archiecture-centred - This implies gathering the requirements collected during the use cases and think of them as classes organised in components with defined roles within a system. Archiecture might be thought of as the information structure as well as the likely operations of said system. The system architecture starts with the user's viewpoints through use cases influenced by implementation factors.

3- Incremental iterations - At each iteration, relevant use cases are analysed according to the chosen architecture. The artefact resulting at the end of every iteration is a system module or an executable version.  The next stage of the iteration involves the next system component to be implemented provided that the current one meets the user's expectations.

4- focus on risk- This means that the most critical use cases are dealt with early in order to solve the most difficult problems first. The highest risk requirements or use cases are usually the ones most likely to be unpredictable in their interaction with the remainder of the components. Thus, understanding them first emables is important to ensure tighter system cohesion.

UP stages

1- Inception: This stage seeks to establish a broad picture of the system. Here the main priorities are limited to requirements, conceptual models and high level use cases. A development plan is also drawn up at this point in order to anticipate the amount of resources needed into the proposed project. The use cases will be incorporated into iterative cycles. Tests and implementation might occur during this stage in case an early prototype is deemed necessary to avoid greater risks, but otherwise these are kept to a minimum.

2- elaboration- Use cases are expanded upon in order to plot a basic architectural model. This means that the use cases are given more details to decide which artifacts will serve as the input/output of the incoming iterations. The conceptual model is revised and gives rise to the logical and physical design of the intended system.

3- construction- With the basic system architecture established, the first release of the software product is the aim of this stage, which is almost entirely dedicated to coding and testing. At this point a basic should have been reached between managers and users about the intended system.

4- transition - The system is deployed to the user's work environment. Usually data transfer from the former system takes place along with the obligatory training course. Any discrepancy picked by the end users are reported to the developers so they can work on the necessary improvements. It's still possible for requirements and code to undergo some minor revisions.