The Project Engagement process as used by the Intersect Engineering team is outlined here to help members and customers better understand what happens when Intersect is engaged for engineering projects.
Further information on Software Engineering can also be found here.
Scoping and Proposal
To commence the engagement Intersect will conduct meetings and review sessions with you and your stakeholders to ensure a good understanding of your objectives, expected outcomes, limitations and risks, is obtained.
From this, Intersect will build a proposal with a high-level design to address your outcomes. Depending on the level of risks and the level of confidence in the proposal, Intersect will work with you to determine if this can be a fixed price engagement, which has guaranteed outcomes but less flexibility, or whether a flexible Time and Materials approach is more suitable. Time and Materials offers the greatest flexibility for change during projects without defined outcomes. The proposal will be presented with a quote. Quotes have 30 days validity, and to proceed with the engagement you accept the quote with a simple online process, and then Intersect can schedule the team members most suited to your project.
Development
Intersect can develop in a methodology that you feel more comfortable in, either waterfall, or agile using Scrum or Kanban. Each of these methodologies are explained below:
Waterfall
Waterfall is a traditional development process where all requirements are gathered and agreed upon up-front before development starts and the entire system is delivered together at one time. This method is comfortable for many, mostly because everything is agreed and the result is predictable, however it provides little flexibility and little insight into the system as it is being built to ensure it is fit for purpose on completion, especially where requirements change as the development progresses.
The process
After acceptance of the quotation, the Intersect project team will go directly into an Analysis and Design process, where detailed requirements will be gathered, documented and refined for the entire system. Any detailed requirements that fall outside the original proposed scope are discussed and either altered or a change request created to track the variations. A system design document is created and validated before moving into construction.
Once the design is approved the entire system goes into development mode. Code is written and the entire system is built. Unless explicitly agreed otherwise unit tests are created and run as part of the development process. Automated functional tests can be agreed, and would be coded after each functional element is completed and able to be run.
Once the entire system, including any approved changes are completed, the entire system moves into Quality Assurance testing. After QA testing is completed the system is presented to you for user acceptance testing.
Interaction and demonstrations.
During a waterfall process , the Intersect project team will meet with you periodically, on milestones, to discuss progress, and any clarifications that might arise during construction and testing. Intersect may also present samples of the system for clarification and informational purposes, but you also recognise that the system may not function until completed in this development methodology.
Scrum
Scrum is an agile methodology where the system is developed in a series of sprints, with small chunks of the system developed in each sprint and reviewed at the end of each sprint.
The Process
The Scrum process starts with understanding the high-level functions and then prioritising them, in importance. At the start of each sprint, the top priority functions are converted to user stories, which tell a small part of the experience that a user will have, and these go into the “Backlog”. Developers select stories from the current sprint and implement them. During the sprints all three teams are active, analysts are writing user stories for the next sprint and clarifying user stories that are blocking developers. Developers are implementing stories and QA testers are testing the stories as they are completed. This results in a production-ready system (if not complete) at the end of each sprint The system is completed when the agreed stories in the backlog are implemented, however, at any time a production ready system could be launched at the customer’s discretion. If new feature requests are identified during development that were not in the original scope of the proposal, then a change request will be created so that these features can be quoted separately.
Interaction and Demonstrations
At the beginning of each sprint, a “Sprint Planning” session is held to prioritise the backlog and alter any functions or stories to ensure that the end product is fit for purpose.
During each sprint periodical meetings called “Stand-ups” are held, these are usually daily, where all team members share what they did yesterday, and plan to do today, as well as any risks or blockers. This allows impediments to be identified early and acted upon to ensure productivity.
At the end of each sprint, there is a “showcase” to demonstrate where the system is currently at and get feedback. New feedback is added to the “Backlog” and can be prioritised for future sprints during “Sprint Planning” sessions.This showcase focusses on any new or changed functionality since the last showcase.
A “Retrospective” is held at the end of each sprint, where the team share their experiences, sprint performance is analysed and continuous improvements are made to the process for future sprints.
Kanban
This is suitable for smaller developments, where there are only one or two developers and a small budget.
The Process
Similar to Scrum in that functions are prioritised, converted to User Stories and added into the backlog, however the developers continue working through the backlog continuously. This approach is much simpler with less overhead for smaller projects with only one or two developers. Developers have a higher level of interaction during the coding phases so continuous improvements happen as a matter of course.
Quality Assurance testing is conducted on each story as it is completed and made available.
Interaction and Demonstrations
Standups are less formal due to the smaller team, and are generally facilitated by an immediate blocker escalation.
Showcase meetings will happen periodically, not at predetermined intervals. Stakeholders are given access to the Kanban Board to re-prioritise and/or update Stories that are in the backlog at any time.
User Acceptance Testing (UAT)
User acceptance testing is the process where you can interact with the system and ensure its functionality, design and usability are as agreed. Intersect can also organise performance and scalability testing, at additional cost, to ensure that the system will meet all your requirements.
Any issues or bugs where the system is not functioning as described can be addressed during the UAT phase as can small adjustments to ensure the system is fit for purpose. Generally the environment here is part of the development landscape and scaled similar to production, unless there are specific reasons otherwise.
At the end of this testing you and your stakeholders approve the system for handover, and product launch.
Handover and Completion
Handover occurs in two phases;
The first handover provides a non-production environment with the entire system available for the stakeholders or their representatives to perform complete testing of all functionality.
The second handover provides the full system in the production environment. This production environment is determined during the course of the project so that it can be implemented and is ready for the system to be deployed. When the production system is deployed there is a short “Validation” test to ensure operational readiness prior to launch.
Where Intersect is not hosting the production system operational documentation will be included in the handover for your technical team.
Post Completion Support and Maintenance
All Intersect Engineering work comes with a warranty period, usually 90 days from production system installation, during this warranty period all elements of the system that were developed by Intersect that are found not to be functioning as per documented requirements will be corrected as a priority.
Software maintenance is available at an additional cost to provide software currency and support on an annual basis beyond this warranty period. More details on this are available here.