Products
Services
Technology
 Process
|
Process Overview
|
| |
The Unified Process (UP) is the core of Corporate Webbing's development process. It is a mature open Software Engineering Process (SEP) from the authors of the Unified Modeling Language (UML). This process is also the basis for the Rational Unified Process (RUP) and the Microsoft Solutions Framework (MSF).
At Corporate Webbing we adapt our process to fit the job at hand. We have a different level of process implementation depending on the project's size and level of programming required. This is known as an Agile Process, and ensures we maintain a balanced process while remaining creative and disciplined.
Depending on the job there will be steps added or removed, which directly affects the number of final artifacts produced.
Projects types include:
- Full enterprise level implementation starting from modeling the business
- Site rework of content
- Site rework of look, feel, and functionality
- Site information architecture rework
- .NET site conversion
- Section addition to an existing site that must match the current site's attributes
- Application addition to a site such as Corporate Webbing's Calendar (CWCalendar 3.1)
As you can see, there are many different implementation levels and flexibility is a must. Below is a list of steps we follow forming the base of our development process.
Click here to see a flowchart of our full base-level process implementation.
|
Phase I- Inception
|
| |
Iteration 1- Business Analysis- This is the stage where we look at all the different processes used to support your customer's needs. Then, we map them into a visual representation. This is the base model used to build a website or application geared toward giving your customers the same satisfactory service online as they are accustom to off line.
| Artifacts Produced: |
| | Business Model- A visual representation of your business processes along with support documentation explaining the processes. |
| | Refined Initial Concept- A description of the initial application, it's expected features and how they will impact the current business processes. |
| | Project Vision Document- A description of our joint goals and definition of the project's scope. |
|
| | |
| |
Iteration 2- Requirements Analysis- Now we take the Artifacts developed and the knowledge gained from the Business Analysis stage and define the requirements of the system to be built.
| Artifacts Produced: |
| | Requirements Document- This includes the functional and non-functional requirements of the system to be built. |
| | Use Cases- This includes the system boundary definition, the actors in the system (who will be using it), the possible scenarios, and the use case diagrams. |
| | Project schedule and finalized budget- Depending on the size of the project this may have been laid out prior to the project beginning. This set of documents is usually generated at this stage for large projects with several implementation stages. |
|
| | |
Phase II- Elaboration
|
| |
Iteration 3- Application Analysis- During the analysis stage we begin to tie the business process objects together to develop a system that includes all the requirements. Here we are making a conceptual model of the problem domain (the requirements and the use cases).
| Artifacts Produced: |
| | Use case realization artifacts- Use case realization is the process of turning your use case diagrams into class diagrams and interaction diagrams. |
| |
|
-Analysis Class Diagrams- These are UML class diagrams that show how the static view of the business classes work together to realize the use cases and requirements. |
| |
|
-Interaction diagrams- These are UML class diagrams that show the dynamic view of the business classes work together to realize the use cases and requirements. This includes sequence, collaboration, component realization diagrams. |
| |
|
-Use case refinement- The use cases are refined as the system is built to reflect any changes resulting form the analysis work flow. |
| | Technical Specifications- This includes coding languages to be used, web server specifications, database server specifications, and other possible technical details that will need to be integrated in the design stage. |
| | Story Boards- A visual mockup of each type of page template is generated. |
| | Site Hierarchy (site map)- A visual representation of the site is created using Visio. |
| | Test Plan- A test plan outlines the scope of testing and the type of testing to be done, and the testing documentation that will be generated to ensure the quality of the application being created. |
| | Prototype- A proof of concept is worked through to ensure the application's logic is sound from the business logic perspective. |
|
| | |
| |
Iteration 4- Application Design- During the design stage the application design is moved from the problem domain (business objects) to the map of the actual application, which the development team works from. Here we are making a physical model (a system that can be implemented) of the solutions domain.
| Artifacts Produced: |
| | SRS (Software Requirements Specification)- The SRS is a combination of all the above artifacts (use cases, sequence, collaboration, component realization diagrams, and technical specifications) from the analysis stage. They are reworked into the design level format. It is a living document, which means it is updated throughout the development process. |
| | Test Cases- The test cases are written using the Requirements Document, the Project Specification (Use-Case Specification, SRS, and the Design Model), Story Boards, and existing prototypes. The point of the test cases is to verify the requirements that the client agreed to buy. Test cases are therefore not written by using the application that is to be delivered. They are written before the application is built. |
|
| | |
Phase III- Construction
|
| |
Iteration 5- Implementation- Implementation is the development of the system. The databases are created, the stored procedures are code, the user interfaces (web pages, windows forms) are coded, the business components are coded, and all of this is tested through code review and a module level QA testing process.
| Artifacts Produced: |
| | Code- Well formatted and commented code for ASP applications, ColdFusion applications, static HTML pages, SQL code for stored procedure and database functions, and COM+ components is created. |
|
| | |
Phase IV- Transition
|
| |
Iteration 6- QA Acceptance Testing- After all the unit (module) testing is done during development the units are integrated into sub-systems which are reflective of the use case's scopes. It is in this stage those sub-systems are tested using the test cases developed during the design stage. At this point all technical functionality should have already been check during the testing test done in development, but this provides a great double check. The test cases that are run at this point are run to insure that the functional requirements and use cases have been met.
As the modules are approved in this area the training documentation is completed for each module.
| Artifacts Produced: |
| | Training Documents- Depending on the scope of the training that is requested by the client and the level of difficulty of the application, this may include power point presentations, word documents, or an HTML Help file. |
|
| | |
| |
Iteration 7- Stakeholder Acceptance Testing- This is the final check for our in-house stakeholders. Any outstanding issues are identified and resolved during this review period.
| Artifacts Produced: |
| | Approval Documents- These are comprised of check lists for the different functionality and areas of the application that was built. |
|
| | |
| |
Iteration 8- Client Acceptance Testing- This is the final check by the customer before the system goes live. Any outstanding issues are identified and resolved during this review period.
| Artifacts Produced: |
| | Approval Documents- These are comprised of check lists for the different functionality and areas of the application that was built. |
|
| | |
| |
Iteration 9- Training and Deployment - Before deployment the users of the systems are trained on any administration tools, section or page updating, or any other needed training is done at this time. Any training documentation created during Iteration 6- QA Acceptance Testing is used as a guide for training and handed off to the customer for use later as reference material.
| Artifacts Produced: |
| | System Configuration Documentation- The deployment diagram is updated at this time and the system configuration details are documented. |
|
| | |
|
