The dynamic nature of ReliSource Software development projects demands full fledged software development process with rapid change cycle. The ReliSource process, leveraging the same interest, derived from agile development life cycle, enables to produce high quality application in rapidly requirement changing scenario.

 

After a thorough study on the practiced agile methodologies (XP and SCRUM) it reveals that both these process follow the basic thumb rule of agile development methodologies yet focus of interest for these two processes is different in terms of goal for real life development challenges. While Extreme programming or XP try to solidify the development cycle in terms of achievable goal and tangible output, the SCRUM process tries to define a process management around agile methodologies. Recently it is being observed that without using any of the agile based process alone it is more logical to use combination of two to extend the usability of the agile development methodologies. 

ReliSource engineering team suggest that these two agile development methodologies not an alternative to each other. It is more logical in real life development scenario that these two processes complement each other. ReliSource process tries to combine both of these two processes to achieve a robust development process with matures sense of project management with minimal overhead.

R-Process is an agile development process to support challenging development environment with dynamic requirement initiation. R-process combines the XP and SCRUM to get the benefit of robust and tangible development cycle from XP and matured yet light weight project management cycle from SCRUM. 

 

 

 

 

 

 

In the project initiation phase, the development team captures the requirement of the project; prepare a project proposal and a project plan from the requirement. In some case the requirements are not well defined or the customer may not have any solid requirement set. In this case, the development team captures the requirement through set of question answering session and discussion meeting. From the captured requirement set, the development team prepares a requirement document and verifies the document with the customer. The deliverables in this phase are as follows:

• Questionnaire set to capture project requirement

• Initial Requirement document

• Project proposal

• Initial project plan

In the project initiation phase there several functional activities which are performed as required basis based on the initial project status and knowledge base of development team about the product the requirement. These functional activities are tuned and performed according to the challenges faces capturing requirement for the product. 

 

In normal activity case, The development team receive requirement set or wish list from the customer which can be easily transform into SRS in the later phase. But in case it can happen that the customer does not have the requirement set or the customer is not totally sure about the requirement. In this scenario, the development team starts capturing the requirements from customer through interaction. Most of the case interaction media are several question answer and discussion session. In some case, the development team prepares requirement sample with more than one suggestion and the client get the option to pick and choose. A high level requirement list is prepared from the result of this session.

In ReliSource process an optional prototype phase is introduces. From real life scenario it is observed that sometimes the product owner doesn’t have the wish list or confused about the complete use-case scenario of the product. It is extremely convenient to do a initial pilot prototype to capture the real use case scenario from the product owner. Sometimes it is also helpful to continue a parallel prototype phase with the real development phase to solidify the product features and user-case. In ReliSource usually large application with client interested with R&D on the product utilize this kind of prototype scope.  

 

 

In this phase Software Requirement Specification is prepared from the initial requirement set. After the SRS is done the initial project in reviewed and extended to detail project plan. The deliverables in this phase are as follows:

• Software Requirement Specification

• Detailed project plan

 

After the project initiation phase, provided that the development team has a detail requirement list from the client, start preparing the Software Requirement Specification (SRS) Document. In the SRS document, each and every system and functional requirements are break into single unit requirement and are document. Each of the unit requirements are assigned with a requirement ID, estimated release target and detail requirement description are provided in the document. 

For every item, in the SRS document, the client and development team get option to add comment on a specific requirement unit. Each and every customer feedback and comment during interaction are added after the requirement section of every requirement unit.

This SRS document usually replaces the need of Story or Product backlog terminology of XP or SCRUM. The basic difference between of the SRS prepared by the ReliSource engineers and the Product backlog in SCRUM is the SRS is much detailed in nature and it tend to solidify the requirement in more rigorous way.

Project plan and scheduling

After the SRS is done, the development team reviews the initial project plan delivered with project proposal and extends the project plan with detailed information. The project plan is done using Microsoft Project or Simple Excel spread sheet according to client convenience. In the detail project plan, required resources are calculated, each minor and major builds are schedules and defines a complete release cycle for the project.

 

In this phase the developers implement the application according to the SRS. The deliverables here are as follows:

• Code base

• Product manual

 

The iteration cycle is planned in detail in the project plan during the planning phase. The iteration phase goes in incremental fashion, identifying which feature or requirement goes to which iteration and each iteration cycle is one to three week long. After each iteration phase, the feedback from customer in captured to incorporate suggestions and changes in the next iteration. During this incremental cycle, the QA team also integrates changes in the test cases and executes regression cycle on the application.  

 

In the ReliSource process QA phase starts from the beginning of the project though the test case execution process start after the minor internal build. At the beginning of the project the QA team gets involved in the project planning and as soon as the SRS is solidified, the QA start working on preparing the test cases. The deliverables in this phase are as follows:

• Test plan (if applicable)

• Test case

• Test matrix

 

In each iteration phase the development team prepares the implemented features for client demo. The features are submitted to the customer to get feedback about the usability and use-cases. Real life feedback is taken from the user to improve and modification of the project. Some of the modification is done instantly and some of them are scheduled for next release. Through this feedback, the product features are tested for its customer acceptance. In case customer changes any features or use-case it is scheduled for later iteration to be implemented.

 

In the deployment phase, the development team integrates the application in the system. Before the production use of the application, the development team runs smoke tests in the system and captures user feedback.  A detail product manual is also provided to help the user to cope with the new product. The development team also runs a knowledge transfer session to make the user familiar with the software and perform training if required. After the application deployment, the development team enters into maintenance phase of the project. Possible deliverables in the phases are as follows:

• Release note

• Training materials

• Requirement set for next release

• Maintenance guideline

Some of the product requires long training phase for the user to get acquaintance with the system. In some cases, the user requires internal knowledge to use the product (development or design tools). In this scenario, ReliSource Development team suggests a knowledge transfer phase to help the user to get deep level knowledge on the product. 

This knowledge transfer phases are normally equipped with training session through WebEx, phone conference and other training materials. 

 

Some of the product requires long term maintenance phase. ReliSource development team provides long term maintenance support for the developed product.