PortaOne's unique development process that combines some of the strengths of traditional software development practices with "agile" programming methods, is designed to provide maximum efficiency in delivering a robust product that satisfies the needs of PortaOne customers.

Our vision is to provide our clients with a platform which evolves as the market and the business environment change; a system which allows PortaOne customers to gain a competitive advantage and successfully expand their ventures; a system they can rely on today, tomorrow, and for many years ahead in the future.

One of the main reasons service providers around the world choose PortaOne is our commitment to quality and our ability to provide a product which constantly evolves and adapts to changing market requirements. The majority of our customers are independent service providers, and their main tool for competing with larger incumbent telco operators is the ability to provide the functionalities that end-users want faster than anybody else on the market.

Needless to say, delivering new functionalities and introducing new services has to be done without compromising the overall stability of the system or disrupting existing service.

Maintenance Releases and Builds

Improving the platform is an ongoing process at PortaOne. However, it is necessarily split into smaller steps in order to simplify migration to the new software version, reduce the amount of training/learning required, and guarantee system stability.

A new functionality (module, feature, change to the web interface layout, etc.) is only introduced as part of a new maintenance release. Maintenance releases are numbered sequentially (e.g. MR26, MR27, MR28, etc.), and so the higher the number, the more recent the software version. PortaOne produces 6 or 7 maintenance releases per year, so the time between maintenance releases is less than 2 months. Within a maintenance release, software development is carried out in iterations, and each iteration results in a software build - a complete set of PortaSwitch code gathered together.

Each build goes through a rigorous testing process to ensure that none of the existing functionalities are disrupted, that the update from the old version goes smoothly, and that the whole package is stable. Builds are also numbered sequentially, the first (initial) build being zero. So the exact name of a specific software version is typically something like MR27-2 (Maintenance Release 27, build 2).

As an example, the list of selected 2012 maintenance releases and builds for these releases is displayed below.

Development Cycle

Each maintenance release starts with careful selection of the features to be included (see below for more details regarding the selection process). For each of them, specifications, prototypes and other supporting documentation are prepared and approved by the project owner.

The first (zero) build normally takes six weeks to produce:

The first two weeks are spent on actual coding activities.

During the third and fourth week, the development team and QA jointly carry out various tests to verify that the new functionality both satisfies the original requirements and does not conflict with any existing code; any reported problems are immediately fixed.

During the fifth week, the QA team runs a vast array of functionality tests to ensure that the new maintenance release is stable.

Finally, during the last sixth week all the necessary preparations are made in order to deliver the build to PortaOne customers. This includes production of installation CDs and upgrade scripts (to update already installed systems), testing an upgrade to this build from other (older) builds and rollback, and so on.

After that, subsequent builds within the given maintenance release involve only bug fixes or minor improvements of the existing functionality. This is why subsequent builds only take three weeks:

one week for coding,

one week for verification and

one week for release production.

This agile process allows PortaOne to offer an unmatchable short waiting time for a new functionality. It takes only 2 to 3 months from the time the customer identifies a business case and submits a feature request until the first version of the functionality is delivered.

The fixed timeframe for each build guarantees the delivery time for PortaOne's customers, so they can plan their activities accordingly.

Leap-Forward and Long-life Releases

The two most important concerns for any service provider are:

How fast can I deploy new service or adjust my system to address the change on the market?

How do I ensure that my system is stable?

The two types of maintenance releases allow customers to:

receive the new functionality in the shortest possible time frame,

verify that everything is working properly (using a staging system or some "pilot" customer set),

wait (if required) for the improvement build, and

update their production system after that.

In case if there is an issue with a leap-forward release, which affects the service provided - the system owner can immediately rollback to the previous release.

The conundrum of combining these two antagonistic desires is solved by offering two types of maintenance releases: leap-forward and long-life.

Most of the releases will be leap-forward releases, meaning that there is new functionality added - for these releases PortaOne team will produce an initial software build and then a single "incremental" build to address any issues that were reported.

The long-life releases are mainly focused on improved system stability - they will be supported longer, there will be multiple incremental builds for a long-life release.

There will be offered a "jump" upgrade from one long-life release to another one (and a rollback possibility), so a customer who is mostly concerned about the overall stability can stay on the long-life releases only.

Selecting Functionality for Maintenance Release

We always appreciate feedback or suggestions from our customers, since this allows us to make our product better. We want our customers to be the driver of product development - after all, they know best what would benefit their business.

Every request for a new feature or improvement (whether submitted via support, the forum, or one of our sales engineers) is analyzed and evaluated for feasibility, architectural integrity, difficulty of implementation and benefit for PortaOne customers. Features are placed on a wish list for assignment to the development roadmap for one of the future releases.

Every day PortaOne receives numerous feature requests, while there is a finite amount of new functionalities that can be put into each maintenance release.

Our main challenge derives from the amount of feature requests we receive - it is physically impossible to implement all of them immediately, or even in the nearest future. Therefore, for each release we have to pick a sub-set of features that we can include.

Naturally, our goal is to focus on those that are most important to our customers and yield the maximum benefit to their business.

When a set deadline for the delivery of a particular feature is required by a particular customer, and that feature has not yet been included in the plan for any upcoming maintenance release, PortaOne may allow this feature to be treated as a custom development. In this case, the customer will cover the development costs for this feature, and PortaOne will commit to including it in the next available release and guarantee a specific delivery date. All custom development projects must be confirmed beforehand, and are subject to resource availability and project planning.

This provides a fair opportunity for any PortaOne customer to prioritize development of the functionality required for their business. The development cost that comes with this forces the customer to make a cost vs. revenue impact analysis - so the decision about which features should be prioritized is made objectively by the customer himself.

In fact, a large portion of the features in each maintenance release are included via the feature request approach described above. This guarantees that we are indeed developing something that our customers need.

Specifications and use cases

To make sure developers deliver the functionality perfectly fitting the original business needs, PortaOne customers are empowered to provide their use cases directly to the development team. This allows the "project stakeholders" in the customer organization who may not have specialized technical knowledge or business analysis experience (e.g. sales or marketing staff) to create and control the specifications so that no information is lost and no time is wasted.

Our goals are:

give customers more control

reduce implementation costs

increase product quality

To help us to achieve those goals, PortaOne customers submit their requirements for new functionality in the form of use cases.

The developers rely on the use cases to choose the best possible architecture and implementation, so that the total implementation cost is kept to a minimum.
Finally, the same use cases are considered by the PortaOne QA team in their tests, and lead to improved product quality.