Anonymous, bureaucrat, administrator
7,528
edits
Changes
no edit summary
One of the questions we are often asked through security questionnaires and how our teams work here internally is "How is bxp developed?"
There is a structured approach we have used since we started with which is continuously refined.
Most of the changes in our solution are inspired by our clients. We learn a lot by simply using the tools ourselves in house. Pitching for new business is a great source of inspiration for doing things in new and improved ways. Our Contact department often get receive new functionality requests , or requests to enhance the platform.
Hamsters and maintenance are other great sources of inspiration which we draw from. Our Security department is never short of new and enhanced ways of refining the processes, procedures and underlying functionality. In fact , all of our departments contribute new ideas [[All_n_One_Departments]]
New modules historically have been born of just from simple ideas. Finding new and innovative ways of dealing with operational headaches or building on other people's views of how things should work.
Every work item, billed or not, becomes a ticket. A ticket can be a massive project with hundreds of jobs or a single ticket with a single job. Jobs are itemised pieces of work that can be solved within 4 to 40 hours. For greater detail on how work can be managed through bxp , and a worked example of the tickets [[Scenario_-_bxp_and_managing_work]]
So depending on the work type of the job, the developers can begin to implement solutions. Some tickets require quotations and reference back to a client , whereas other pieces of work can be done for internal departments.
To give an example build for clarification purposes. "Create a new function to clean phone numbers." The design of the function has already been scoped by the initial request. If further clarification is required more communication happens.
The job is then passed to another developer to test (you're not allowed to our policy states that no developer can test your their own code). Using the a combination of the original requestedrequest, feedback from the developer , and the appropriate testing solution , an iterative process is applied to "test > document > fix" , which is applied.
When tested , the code is then put into the live environment through a number of auditable mechanisms integrated into bxp.
As all functionality on the bxp platform is common to all client systems, considerable thought is given to the go live approach for solutions. The order of Go Live changes depending depends on the work. Where potentially potential operational stopping mistakes errors could happen occur, the code is made put live out of hours.
If the functionality does what is requiredimplemented correctly, then a supporting Wixi is created and releasereleased to clients on our public domain.