How bxp is developed - Revision history

Philip Lacey at 12:25, 4 May 2015

2015-05-04T12:25:36Z

Philip Lacey at 10:19, 21 April 2015

2015-04-21T10:19:56Z

Philip Lacey at 10:19, 21 April 2015

2015-04-21T10:19:32Z

Philip Lacey at 10:17, 21 April 2015

2015-04-21T10:17:22Z

Philip Lacey: 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..."

2015-04-20T17:29:55Z

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..."

New page

= 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 we have used since we started with is continuously refined.

The current organisational development approach is detailed.

= Phases =

== Phase 1: Sources ==

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 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 ideas. Finding new and innovative ways of dealing with operational headaches or building on other people's views of how things should work.

== 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.

== 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 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 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 (you're not allowed to test your own code). Using the combination of the original requested, feedback from the developer and the appropriate testing solution an iterative process is applied to "test > document > fix" is applied.

== Phase 4: Go Live ==

When tested the code is then put into the live 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 on the work. Where potentially operational stopping mistakes could happen the code is made live out of hours.

=== Documentation and Client support ===

If the functionality does what is required, then a supporting Wixi is created and release.

Information about the development, if significant enough is included in our monthly newsletters and social media as well.

[[Category:Topic:About bxp]][[Category:Security]]

← Older revision		Revision as of 12:25, 4 May 2015
Line 82:		Line 82:


−	[[Category:Topic:About ~~bxp~~]][[Category:Security]]	+	[[Category:Topic:About All n One]][[Category:Topic:Security]]

← Older revision		Revision as of 10:19, 21 April 2015
Line 18:		Line 18:


−	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 receive new functionality requests, or requests to enhance the platform.	+	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.

← Older revision		Revision as of 10:19, 21 April 2015
Line 2:		Line 2:


−	One of the questions we are often asked through security questionnaires and how our ~~teams~~ work internally is "How is bxp developed?"	+	One of the questions we are often asked through security questionnaires and how our team work internally is "How is bxp developed?"


−	~~There is~~ a structured approach ~~we have used~~ since we started which is continuously refined.	+	We use a structured approach since we started which is continuously refined.

@@ Line 2: / Line 2: @@
-One of the questions we are often asked through security questionnaires and how our teams work here is "How is bxp developed?"
+One of the questions we are often asked through security questionnaires and how our teams work internally is "How is bxp developed?"
-There is a structured approach we have used since we started with is continuously refined.
+There is a structured approach we have used since we started which is continuously refined.
@@ Line 18: / Line 18: @@
-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 new functionality requests or requests to enhance the platform.
+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 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]]
+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 of just ideas.  Finding new and innovative ways of dealing with operational headaches or building on other people's views of how things should work.
+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 (you're not allowed to test your own code).  Using the combination of the original requested, feedback from the developer and the appropriate testing solution an iterative process is applied to "test > document > fix" is applied.
+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 depending on the work.  Where potentially operational stopping mistakes could happen the code is made live out of hours.
+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 does what is required, then a supporting Wixi is created and release.
+If the functionality is implemented correctly, a supporting Wixi is created and released to clients on our public domain.