Difference between revisions of "How bxp is developed"
From All n One's bxp software Wixi
Philip Lacey (talk | contribs) (Created page with "= Overview = One of the questions we are often asked through security questionnaires and how our teams work here is "How is bxp developed?" There is a structured approach...") |
Philip Lacey (talk | contribs) |
||
| (3 intermediate revisions by the same user not shown) | |||
| Line 2: | Line 2: | ||
| − | One of the questions we are often asked through security questionnaires and how our | + | One of the questions we are often asked through security questionnaires and how our team work internally is "How is bxp developed?" |
| − | + | We use a structured approach since we started which is continuously refined. | |
| Line 18: | Line 18: | ||
| − | Most of the | + | Most of the updates to 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 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 | + | 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 departments contribute new ideas [[All_n_One_Departments]] |
| − | New modules historically have been born | + | New modules historically have been born 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. |
| Line 34: | Line 34: | ||
| − | 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]] | + | 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]] |
| Line 44: | Line 44: | ||
| − | 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 other pieces of work can be done for internal departments. | + | 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. |
| Line 50: | Line 50: | ||
| − | To give an example build for clarification purposes. "Create a new function clean phone numbers." The design of the function has already been scoped by the initial request. If further clarification is required more communication happens. | + | 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. |
| Line 60: | Line 60: | ||
| − | The job is then passed to another developer to test ( | + | The job is then passed to another developer to test (our policy states that no developer can test their own code). Using a combination of the original request, feedback from the developer, and the appropriate testing solution, an iterative process is applied to "test > document > fix", which is applied. |
| Line 67: | Line 67: | ||
| − | When tested the code is then put into the live through a number of auditable mechanisms integrated into bxp. | + | 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 | + | 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 depends on the work. Where potential operational errors could occur, the code is put live out of hours. |
| Line 76: | Line 76: | ||
| − | If the functionality | + | If the functionality is implemented correctly, a supporting Wixi is created and released to clients on our public domain. |
| Line 82: | Line 82: | ||
| − | [[Category:Topic:About | + | [[Category:Topic:About All n One]][[Category:Topic:Security]] |
Latest revision as of 13:25, 4 May 2015
Contents
1 Overview
One of the questions we are often asked through security questionnaires and how our team work internally is "How is bxp developed?"
We use a structured approach since we started which is continuously refined.
The current organisational development approach is detailed.
2 Phases
2.1 Phase 1: Sources
Most of the updates to 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 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 departments contribute new ideas All_n_One_Departments
New modules historically have been born 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.
2.2 Phase 2: Tickets
Every item of work to be done is created initially as a Ticket in the All n One bxp system. Each ticket is then scoped and refined into separate Jobs.
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
Each of these work items are then prioritised and allocated to appropriate internal team resources to execute. The "Technical Operations Manager" manages all the projects and ensures their timely delivery.
2.3 Phase 3: Builds
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.
Scoping and definition change greatly depending on the work type.
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.
Each of the tickets will affect one or more of the All n One Infrastructures. All n One Infrastructures
The build itself is performed in the testing environments of All n One. Using a combination of centralised testing facilities and locally hosted instances, developers build the code to deliver the ticket.
The job is then passed to another developer to test (our policy states that no developer can test their own code). Using a combination of the original request, feedback from the developer, and the appropriate testing solution, an iterative process is applied to "test > document > fix", which is applied.
2.4 Phase 4: Go Live
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 depends on the work. Where potential operational errors could occur, the code is put live out of hours.
2.4.1 Documentation and Client support
If the functionality is implemented correctly, a supporting Wixi is created and released to clients on our public domain.
Information about the development, if significant enough is included in our monthly newsletters and social media as well.
