Rapidiant uses the Rational Unified Process (RUP) engineering and agile DevSecOps development framework, methods, and techniques in support of its software development projects. Rapidiant’s approach uses four (4) distinct project life cycle phases that allows the process to be presented at a high level in the beginning while evolving into more detail as iterations of development are executed. Rapidiant’s RUP development approach is where we break down and manage the work through a series of distinct iterations and activities as depicted in Figure 1.
Figure 1 – Rapidiant’s RUP Approach
Rapidiant’s approach as depicted in Figure x above is a highly iterative and incremental implementation practice where developers and project stakeholders actively work together to understand the domain, identify what’s needed to be built, and can continuously prioritize functionality. These phases allow the RUP process to be presented at a high level in a similar way to how a waterfall-styled project might be presented while in essence the key to the process lies in the iterations of development within all of the phases. When the project value is clear, our agile DevSecOps development team along with the customer actively participates throughout the implementation of the project where the customer, designers, and developers are co-located, incremental feature-driven development is possible; and visual, animated, and graphic screen shot documentation is acceptable. Rapidiant’s typical Project Life Cycle (PLC) development phases for agile DevSecOps development projects are outlined as follows:
- Initiate – this is where we scope out the project requirements for establishing a vision statement and a basis for validating the initial costs and financial prognosis. In this phase, the business case which includes business context, success factors (i.e., expected revenue, market recognition, operational business outcome, etc.), and financial forecasts are established. To complement the business case, a basic use case model is defined, an initial project plan is established, an initial risk assessment is articulated, and project description of core project requirements, components, constraints, and key system and technical features are defined. This phase normally includes the development of the following multiple analyses as required by the project sponsors, stakeholders, and its system owners:
- Analyze the business needs and requirements in measureable goals, objectives and key performance indicators
- Review current operations and business practices, and identifies operational deficiencies and system vulnerabilities
- Establish a financial analysis of the costs and benefits to include an initial budget estimate or prognosis
- Develop an analysis of stakeholders by identifying the executive managers, project sponsors, system owners, end users, and support personnel
- Establish and develop a Project Charter which includes costs, tasks, deliverables, and schedules
- Provide a SWOT analysis highlighting the strengths, weaknesses, opportunities, and threats to the business
In this phase, the team meets regularly to determine the project’s necessity, but also its viability and suitability. It is then normally checked against the following criteria:
- Stakeholders and system owners concurrence on scope, definition, and schedule/costs estimates
- Requirements understanding as evidenced by fidelity of the primary use cases and scenarios
- Credibility of schedule/cost estimates, priorities, risks, and development process
- Depth and breadth of developed architectural prototypes
- Established baseline for comparing actual expenditures against planned expenditures
- Develop – this phase involves the planning of the project to an appropriate level of detail from the preceding analyses in order for the project to take shape. In this phase, the problem domain is highlighted and documented, system requirements are assessed and analyzed, and an executable architecture begins to evolve and take shape. In this phase, Rapidiant will specifically:
- Develop use case models or diagrams where the use cases and the actors have been identified and most of the use-case scenario descriptions are 80% complete
- Describe the project scope by the identifying the opportunity or problem and what results must be achieved based on the use case scenarios and the prototype architecture
- Divide the project into tasks, identify the deliverables, and create the work breakdown structure (WBS)
- Identify the activities needed to complete the deliverables and estimate the resources requirements for the activities
- Develop a preliminary project plan with a schedule and assign time estimates to each iterative activity in the WBS
- Determine project and technical specification standards and procedures for ensuring architecture and technical compliance in development, engineering, and testing;
- Identify potential risks and assess the consequences of those risks
- Develop a preliminary budget that summarizes the planned expenses and forecasted revenues related to the project
- Develop a statement of work for the baseline project plan that describes the work to be accomplished and the overall expected business outcome of the project
- Develop a baseline project plan that estimates the required resource requirements for the project milestones, tasks and activities
The results is then normally checked against the following criteria:
- Is the prototype architecture stable?
- Are the use cases and scenarios detailed and accurate based on the business case?
- Are the important risks being tackled and sufficiently analyzed?
- Is the project development plan sufficiently detailed and accurate?
- Do all interested parties agree on the current design?
- Are the planned expenditures and cost estimates acceptable?
- Build – this phase is where we build the system through the iterative development of a series of components and features in accordance with a Release Plan. It involves proper allocation, coordination and management of resources such as personnel, materials and budgets. This phase is where the majority of the coding and system configurations take place through the construction of several iterations where the use cases and their use case diagrams have been divided and developed into manageable segments that can produce demonstrable prototypes. The output of this phase is where the first working software segment is released in accordance with a release plan. The project management techniques employed in this phase include:
- Executing the baseline project plan by initiating the implementation of project activities, acquire and assign resources, orient and train new team members, keep the project on schedule, and assure quality in project deliverables
- Managing changes to the baseline project plan as a result of necessary design modifications, differing site conditions, material availability, personnel emergencies, value engineering, and impacts from third parties, to name a few through a change management process for ensuring compliance with architecture and standards
- Managing the project workbook by maintaining complete records on all project events for producing project status reports and reviews
- Continually communicating the project status through daily SCRUM standup meetings, weekly activity reports and monthly status reviews/reports with the entire project team so that everyone understands how the plan is evolving, what risks are being mitigated, and what working software segments are working. .
- Measuring the ongoing project activities and where we are relative to schedule
- Monitoring project variables (cost, scope, effort and performance) against the project plan and the project performance baseline for measuring earned value
- Identifying corrective actions for addressing issues and risks properly
- Influencing factors that could circumvent integrated change control so only approved changes are implemented
The results from this build/production phase include:
- A fully completed software system through development of all releases outlined in the Release Plan
- A stable product that is complete enough for end user use
- All interested parties and end users are ready for transition into deploy and production release
- All expenditures, project activities, and program use stories are completed and in good operating order
- Transition – this phase includes the transition of the stable working system from development and build into production. This includes making it available to and understood by system owners and end users. The activities of this phase include training the end users and maintainers and beta testing the system for validating that it meets end user, system owners, and stakeholders’ expectations. In the beta testing of the system, an integrated System Acceptance Test (SAT) and User Acceptance Test (UAT) are formally conducted for transitioning the system into production. In addition, this phase includes:
- Closing down the project by notifying all interested parties and stakeholders on completion of the project and finalization and transfer of all project documentation and records
- Conducting post project reviews to determine the strengths and weaknesses of project deliverables, the processes used to create them, and the project management processes and developing lessons learned for increasing efficiency and effectiveness in future endeavors
- Closing the contract for ensuring all contractual terms have been met and administrative and project or task order final invoicing and payments has been completed.
The business outcomes and results from the transition phase include:
- Successful beta testing of the system
- Conversion of existing user databases
- Training of system owners and end users
- Rolling out of the project for deployment and end user execution
Moreover, Rapidiant uses the Rolling Wave planning process on agile DevSecOps projects for evolving and engineering a solution over a continuous iterative period of time. This technique produces better results in meeting requirements and achieving performance than a sequential phased approach like “Waterfall”.
Our process is where planning of a project is progressively done in waves as depicted in the Figure 2 and the project system incrementally unfolds. Short term iteration activities are planned at a more detail level while longer term activities which are further away are planned at a lower level. Our Rolling Wave planning approach is particularly useful when the requirements are dependent on the outcome of some or all of the near term planning. This planning technique allows us to acknowledge that everything is not known at the start of a project and we allow the project to unfold over time. This agile planning approach produces better results and greater performance than the Waterfall phased approach where project improvements would have to be accomplished after implementation and deployment under a System Improvement Plan. Rolling Wave planning permits work activities to move forward on current and near term deliverables while planning is still ongoing for the latter work release packages. This approach is particularly useful when the availability of the information needed to plan future work packages in detail is predicated on successful completion of previous iterative project phases. This technique helps shorten time by making it possible for productive activities to begin without waiting for every detail of the work project to be determined in advance; and by eliminating downtime for additional planning in the middle of a project execution since planning is done continuously.