TECHNICAL REVIEW OF
`DIGIFONICA VOIP SYSTEM
`
`Author: John Rutter / Stuart Gare
`Date: 05/07/2005
`Version V0.7 (Draft)
`Company Confidential
`
`Voip-Pal Ex. 2003
`IPR2016-01201
`
`

`

`TECHNICAL REVIEW FOR DIGIFONICA VOIP SYSTEM
`
`Contents
`
`1
`
`3
`
`Introduction
`1.1 Background
`1.2 Review Stages
`2 Management Summary
`2.1 Summary Introduction
`2.2 Calculated Results
`2.3 Key Conclusions
`2.4 Summary Comments
`2.4.1 Company Approach
`2.4.2 Software Development
`2.4.3 System Documentation
`2.4.4 Performance Testing
`2.5 Next Steps
`Technical Review Process
`3.1 Scope
`3.2 Areas of Review
`3.2.1 Documentation
`3.2.2 System Architecture and Design
`3.2.3 Software Platform
`3.2.4 Development Process and Change Control
`3.2.5 Source Code
`3.2.6 Test Procedures and QA
`3.2.7 System Functionality
`3.2.8 Miscellaneous
`3.3 Results Calculation
`3.3.1 Interpretation
`Review Detail Comments
`4.1 Actual Review Process
`4.1.1 Areas Covered By Review
`4.2 Calculated Results
`4.3 Review Topics
`4.3.1 Documentation
`4.3.2 System Architecture and Design
`4.3.3 Software Platform
`4.3.4 Development Process and Change Control
`4.3.5 Source Code
`4.3.6 Test Procedures and QA
`4.3.7 System Functionality
`4.3.8 Miscellaneous
`Follow-up Activities
`5.1 Digifonica Tasks
`5.2 Smart421 Assistance
`Appendix A – Glossary
`Appendix B – Review Resources
`
`4
`
`5
`
`3
`3
`3
`4
`4
`4
`4
`5
`5
`5
`5
`5
`6
`7
`7
`7
`8
`8
`8
`8
`8
`8
`8
`8
`9
`9
`11
`11
`11
`11
`12
`12
`13
`17
`20
`22
`23
`25
`27
`28
`28
`28
`29
`30
`
`Digifonica Technical Review v0.7.doc
`
`page 2 of 35
`
`

`

`TECHNICAL REVIEW FOR DIGIFONICA VOIP SYSTEM
`
`1 Introduction
`
`1.1 Background
`Smart421 have been engaged to perform a high level technical review and appraisal of the Digifonica
`VoIP (Voice over Internet Protocol) application software and development processes. The review team
`from Smart421 consists of two experienced technical staff, assigned over a period of three weeks.
`
`Digifonica are an international telecommunications company, having their development offices based
`in Vancouver, Canada. They have developed a VoIP solution that utilises hosted systems and leased
`network links across the globe, such that VoIP calls made over this network can be reliably routed and
`controlled within this environment.
`
`VoIP provision is provided by Digifonica as a wholesale service through a range of reseller
`arrangements. Resellers or partner companies are given a ‘white box’ or unlabelled service that they
`can customise to suit their own markets and customer base, including pricing and packaging terms.
`
`Digifonica do not plan to offer the VoIP service to end customers directly, only providing the service
`through partner companies, who also have the responsibility of providing first-line support to their
`customers. Initial services are offered to ‘Tier 3’ level partners, with Digifonica managing the network
`hardware and customer management back-end systems. Higher level partners will be provided with
`integration facilities to work with Tier 1 and Tier 2 customer and billing database systems.
`1.2 Review Stages
`The technical review has being performed in three consecutive stages, as follows:
`
`Stage 1 – Initial System Appraisal, Document Review (UK)
`
`Receive high-level documentation to gain familiarity with the system.
`Perform early analysis and review of provided documentation.
`Identify areas for more detailed technical review.
`Produce Stage 1 Report indicating progress so far
`
`Stage 2 – Technical Review of Code and Processes (Canada)
`
`Travel to Vancouver to visit Digifonica offices and staff.
`Investigate development processes and use of standards.
`Meet with team members for question-and-answer sessions.
`Perform code review on selected components.
`
`Stage 3 – Report Completion and Presentation (Canada/UK)
`
`Update report with latest findings.
`Perform internal review of document against Smart421 standards.
`Present final review document to Digifonica.
`
`Digifonica Technical Review v0.7.doc
`
`page 3 of 35
`
`

`

`TECHNICAL REVIEW FOR DIGIFONICA VOIP SYSTEM
`
`2 Management Summary
`This section of the document provides the highlights of the full report, for use where the reader does
`not require the detailed information as described in subsequent sections of the report.
`2.1 Summary Introduction
`The review process was performed by Smart421 with the full co-operation of staff at Digifonica.
`
`One of the impressions gained from the review was of the willingness of those staff to assist in
`providing all required information, with no apparent hiding of technical or operational issues.
`
`Stage 1 of the review process provided a good understanding of the overall system, covering the
`requirements and functionality of the Digifonica VoIP solution. Stage 2 involved meeting key
`personnel within Digifonica to discuss and further understand the processes and system design used
`by the company.
`
`The second stage of the review helped to identify the distinction between the current ‘Version 1’
`implemented system environment, the ‘Version 2’ development under way at present, and other
`features that could be incorporated in any future releases.
`
`The distinction between the different development versions or phases has been applied to generate
`different sets of results from this review, to allow the report to indicate the immediate position and
`the position that the company is directly moving towards. This highlights the actions already being
`taken by Digifonica to address potential issues in the current platform, which is a positive step and
`not to be taken as any particular failure in company operations.
`2.2 Calculated Results
`Tables in the detailed section include numeric figures that show a simple percentage representation
`so that ranking of areas of the system can be compared for ‘completeness’ and ‘surety’.
`
`For a full explanation and breakdown of these figures, repeated below, refer to later sections of this
`document that describe their generation and interpretation.
`
`Average Percentage ‘Complete’
`Average Percentage ‘Surety’
`
`Version 1
`(Current)
`56%
`63%
`
`Version 2
`(Planned)
`85%
`88%
`
`Also note that it is generally unrealistic to expect any organisation to generate a 100% ranking in
`results of this sort, whether that is a new company or an older, well-established company. A
`reasonable target for most companies
`
`A pragmatic approach to live service delivery is much more important than having an organisation
`that restricts operations with large administrative overheads, which may be the only way to achieve
`maximum review results.
`2.3 Key Conclusions
`In summary, the main points drawn from this review are bulleted below:
`
`(cid:120) Documentation – clear and concise at a high level, would benefit from more technical content,
`as expected to arise during the Version 2 development process
`(cid:120) Design and Code – designed for scalability, reliability and flexibility; well structured code
`following good practices with peer review to verify correctness of developed programs
`(cid:120) Development Process – historical process was lighter but well controlled; new process in place
`for subsequent development now more formal, as expected of a company now responsible for
`live service provision and maintenance
`Test and QA – testing now also more formal and with greater coverage then earlier releases
`(cid:120)
`(cid:120) General – company culture is correct with strong emphasis on reliable service delivery;
`recruitment has attracted experienced technical staff for the main development team; team
`management appears to be well structured and controlled; further processes will be needed to
`maintain the exchange and recording of information as the company grows further still.
`
`Digifonica Technical Review v0.7.doc
`
`page 4 of 35
`
`

`

`TECHNICAL REVIEW FOR DIGIFONICA VOIP SYSTEM
`
`2.4 Summary Comments
`Particular points and comments drawn from the technical review are listed below.
`
`2.4.1 Company Approach
`Digifonica has seen some recent expansion in staff over the past few weeks and months, increasing
`both technical capacity and sales and management for operational activities. During this time, the
`technical side of the company has implemented more formal methods to the design, code and test
`process. This addresses the potential issues identified from the historical development phase.
`
`Project management activities have been well controlled in both phases of the company, and the
`newer development process ties in well with the approach used in tracking new features and releases.
`
`The company has a clear commitment to the creation and delivery of a reliable and robust service,
`with a strong view to using existing standards and technologies in association with their own custom
`developments to create the Digifonica VoIP system that has the necessary technical controls needed
`to incorporate the desired functionality of the managed service.
`
`2.4.2 Software Development
`During the review, it was apparent that development of the core technology had been performed over
`a longer period of time by a small number of key technical staff. During this stage, formal process had
`been kept to a minimum. This was balanced by the commitment to quality shown by these staff, and
`information exchange between individuals ensured that developed was well controlled.
`
`It seems that the web-based application area had been written more recently, in a shorter space of
`time. This is seen as something of an ‘add-on’ to the call-handling core components of the system,
`although equally important in the provision of the overall VoIP service. Some deficiencies were
`spotted in the initial web-app implementation, although these were not viewed as overly important
`and not critical at this stage.
`
`At the coding level, there is a clear split between the core functional components and that of the web
`applications in support of the complete system. The core code appears to be very well written and has
`been tested in live operation and destructive testing by developers over a period of time. This gives a
`high level of confidence in the call-handling capabilities of the system.
`
`The current web application does not appear to be so far along the development path, although it
`seems to be fully functional and usable for Tier 3 customers as intended. The deficiencies in this area
`of application code are expected to be resolved in the Version 2 software release, where stricter
`design and development processes are in place.
`
`2.4.3 System Documentation
`At the design level, some additional documentation would be useful to describe the breakdown of core
`components and their interactions and interfaces. At present, this information is understood by
`current team members, but requires an informal process to bring on additional technical staff. If fully
`documented, this could shorten the training time needed for familiarisation of system operation as
`new staff become involved in development or support. It would also assist any external companies
`that may be involved in integration or custom development tasks.
`
`The absence of this level of documentation is not a major problem and does not point to poor design
`practices, it is just noted as an area of some deficiency. It is also noted that the newer development
`process will generate further documentation for new features and new releases. This approach is
`likely to remedy the documentation shortage over time, reducing or removing this as an issue.
`
`2.4.4 Performance Testing
`Performance metrics for the system have not yet been proven, due to the unavailability of a suitable
`test environment to drive the system at high loads or throughput levels. Test plans are in place to
`generate the benchmarks and volumetrics figures for various combinations of Digifonica software and
`hardware components. It is viewed that these tests, when performed, will provide accurate and
`usable figures for use in determining the throughput and scalability of the system.
`
`Digifonica Technical Review v0.7.doc
`
`page 5 of 35
`
`

`

`TECHNICAL REVIEW FOR DIGIFONICA VOIP SYSTEM
`
`Until these benchmarks can be generated, estimations have been calculated from known capabilities
`of network and software components used within the system. As the lower-level figures are multiplied
`up in the mathematical models, the results at each stage have had reductions applied in an order of
`magnitude to generate pessimistic figures. It is hoped that these figures can then be easily exceeded
`from tests in the live environment, as losses are not expected to be as high as used in the
`calculations.
`
`This approach is much preferred over simplistic calculations that multiply up low-level numbers by
`scaling factors without allowing for losses that arise as system increase in size and complexity. In this
`case, the quoted benchmark target figures seem reasonable and achievable, although that can only
`be confirmed by the execution of the relevant performance tests. Even so, there is not yet any proof
`of outright system performance capabilities, only targets set for the system installation.
`2.5 Next Steps
`Areas of some deficiency have been noted in this report, for which Digifonica are already addressing
`the potential problems. In particular, these cover:
`
`Additional Technical Documentation
`(cid:120)
`Formal Development Process
`(cid:120)
`Performance Test Benchmarks
`(cid:120)
`(cid:120) Web Application Design and Implementation
`(cid:120) Database Performance and Design
`
`Following this review, Smart421 are able to continue working with Digifonica on a technical level. This
`would provide further benefits from the investment in time and effort already expended in
`understanding and reviewing the Digifonica VoIP solution.
`
`Activities in which Smart421 can work with Digifonica include the following:
`
`An update to this Technical Review, to report on Version 2 results
`(cid:120)
`Validation of Performance Test Benchmarks
`(cid:120)
`(cid:120) Database Tuning activities
`Verification of any source code lodged for Escrow purposes
`(cid:120)
`Tier 1 and Tier 2 customer data integration activities
`(cid:120)
`
`Digifonica Technical Review v0.7.doc
`
`page 6 of 35
`
`

`

`TECHNICAL REVIEW FOR DIGIFONICA VOIP SYSTEM
`
`3 Technical Review Process
`3.1 Scope
`The review process performed by Smart421 covers different areas of the Digifonica application
`environment, from architecture and design through to development, testing and deployment. Due to
`the limited timeframe allotted for this process, coverage will not be complete, but will instead
`concentrate on specific areas to identify and report on the approaches taken by Digifonica.
`
`This report aims to cover the following points:
`
`(cid:120)
`
`(cid:120)
`(cid:120)
`
`Technical appraisal of system architecture and design to assess its suitability for the creation
`of a scalable and flexible environment
`Review of supplied design documentation to assess completeness and suitability
`Code review of selected components to verify general competence, the use of standards, and
`to check for maintainability of the source code.
`Review of process documentation covering the software development lifecycle, to report on
`completeness, use of industry practices, standards, quality control and relevant level of detail.
`(cid:120) Overview of service management capability for the provision of the VOIP call handling
`environment, the system management software environment, customer provisioning and
`billing systems, and reseller integration capability.
`High level assessment of built-in redundancy, reliability and failover capability of system
`components that comprise the overall Digifonica VOIP application software.
`
`(cid:120)
`
`(cid:120)
`
`The review does not include any assessment of the commercial viability or marketability of the
`application nor its potential patentability. This is a technical review only, with limited scope.
`3.2 Areas of Review
`The following diagram indicates conceptual areas to be covered by the technical review. Colour coding
`is used to show the areas covered in the first two stages of the review.
`
`System Functionality
`
`Digifonica System
`
`Test Procedures
`
`Source Code
`
`Development & QA
`
`Software Platform
`
`Architecture & Design
`
`Documentation
`
`Legend
`
`Stage 1 Review
`
`Stage 2 Review
`
`The sections below describe the topics to be covered in each area of the technical review.
`
`Digifonica Technical Review v0.7.doc
`
`page 7 of 35
`
`

`

`TECHNICAL REVIEW FOR DIGIFONICA VOIP SYSTEM
`
`3.2.1 Documentation
`Comment on suitability, coverage and completeness of supplied documentation; review to determine
`whether documents are of a suitable level for use during development as well as for subsequent
`maintenance; comment on any obvious areas of omission or deficiency if applicable.
`
`3.2.2 System Architecture and Design
`Perform an appraisal of the overall system architecture, to determine if that is suitable for
`development of the VoIP application software with a view to potential scalability and reliability issues;
`review the design documentation to see that it fits with the stated architectural view for the system;
`identify if the design includes common 'design patterns'; comment on suitability of design to
`incorporate future enhancements when identified.
`
`3.2.3 Software Platform
`Summarise the technologies used across the overall system; to the level of operating systems,
`commercial or open source packages and tools, standards-based interfaces; comment on any
`apparent benefits or drawbacks of the software being used alongside the custom application.
`
`3.2.4 Development Process and Change Control
`Identify the approach taken towards software development, covering design stages, documentation
`and source control mechanisms, team/individual practices for development; continuous integration
`techniques, review processes (for code and design); highlight strengths or weaknesses that may
`appear from the practices that are applied during development.
`
`Perform high-level appraisal of the change control process used by Digifonica; tied in with source code
`control, release labelling and tracking; check for evidence that the process has been used; comment
`on any apparent deficiencies or problems identified.
`
`3.2.5 Source Code
`Check for definition of coding standards and confirm that they have been applied during development;
`verify that general coding style meets generally accepted practices for reliability, readability and
`maintainability; indicate if the reviewed code would be easily enhanced or integrated by external
`software developers; check that code corresponds to the documented design of the system.
`
`3.2.6 Test Procedures and QA
`Review the approach taken towards testing of software, in development as well as in production
`deployment environments; look for defined processes, test plans, test reports, remedial actions;
`overview of areas or levels covered by testing (unit tests, integration, continuous build, pre-release,
`regression, commissioning, acceptance, etc).
`
`Perform high-level appraisal of the quality assurance and change control process used by Digifonica;
`tied in with source code control, reviewing, quality control, release labelling and tracking; check for
`evidence that the process has been used; comment on any apparent deficiencies or problems.
`
`3.2.7 System Functionality
`Appraisal of overall system functionality implemented, against design and general system
`requirements; to include call handling technology, customer provisioning and billing engine, reseller
`web site and application integration; determine whether or not the functionality appears to work
`correctly, and if processes are in place to track faults and change requests to continue to add to the
`functionality in a controlled manner to meet new requirements.
`
`3.2.8 Miscellaneous
`Report on any other points that may be identified during the review process, where that may have an
`effect (good or bad) on the technical solution offered by Digifonica; this may encompass the office
`environment, distributed development team, backup processes, test environments, staff certification
`and training. This is not intended to cover business or operational issues, other than where technical
`operations may have an impact directly on development or live service provision.
`
`Digifonica Technical Review v0.7.doc
`
`page 8 of 35
`
`

`

`TECHNICAL REVIEW FOR DIGIFONICA VOIP SYSTEM
`
`3.3 Results Calculation
`As the different areas of the system are reviewed, an assessment is recorded to allow the calculation
`of an overall percentage figure applicable to the system under review.
`
`Two figures are generated for each area of the review, being the perceived levels of ‘completeness’
`and ‘surety’ against the relevant level. These are not calculated on an entirely mathematical basis, as
`the different areas of review do not lend themselves to absolute calculations of this sort.
`
`This mechanism allows for the creation of a simplified form of summary results, for which any areas
`that appear deficient can then be investigated further according to the detail within this report.
`
`3.3.1 Interpretation
`It may appear that some of the percentage figures are somewhat arbitrary, but they have been
`generated to provide an easily visible representation of the findings of this review. The two types of
`figures are described below to explain how they are to be understood by the reader.
`
`In addition, there are two further classifications that have been applied during the creation of this
`review report. The first is in identifying a distinction between Version 1 and Version 2 development
`phases. Of these, Version 1 is the historical development path leading to the current live system, and
`Version 2 is a newer development path that has been implemented in recent months to include more
`formal measures against software deliveries.
`
`The figures for completeness and surety against both Version 1 and 2 software paths cover areas of
`more and less technical effect. It can be viewed that some of these areas are of greater importance in
`the provision of the live service, whereas others are more related to control processes and ongoing
`development. So that the reader can identify the difference between these types of areas, average
`figures are provided for both ‘hard’ and ‘soft’ technical review results, as described below.
`
`3.3.1.1 Completeness Figures
`The percentage figures listed for ‘completeness’ are determined according to the expected amount of
`material that may come under the relevant topic heading, and the amount provided for review. Where
`only a small percentage of material has been provided, compared to what may be expected, this will
`result in a lower percentage value for ‘completeness’.
`
`3.3.1.2 Surety Figures
`The ‘surety’ figure under each topic heading can be viewed as an inverse ‘level of risk’ for that area of
`the system. A high percentage figure indicates that the review process has found satisfactory results,
`whether this covers documentation content, code construction, or system testing. A lower percentage
`figure may highlight an area in which remedial effort may be required to address potential problems
`or omissions.
`
`If a topic area has a low ranking for completeness, the corresponding surety value will also be lower.
`It would be incorrect to apply a high ranking figure for surety against only the information seen at
`review, since the ‘missing’ parts indicated by the lower completeness figure have to be assumed to
`also result in a lower level of surety.
`
`3.3.1.3 Average Percentages
`Overall average values are provided for Version 1 and Version 2 results, which provide general figures
`for the completeness and surety of the current and planned system releases.
`
`A low ranking figure in either area does not specifically mean that there are problems within the
`system, only that no evidence has been found to come to a reliable conclusion either way and that the
`review results must necessarily present a pessimistic view unless proven otherwise.
`
`For those review areas that have a high figure for completeness, then the corresponding value for
`surety can be deemed to be more accurate.
`
`3.3.1.4 Hard and Soft Technical Areas
`To further assist interpretation of the summary figures, with a view to identifying the areas that are
`deemed more ‘important’ in operation of a live service, the topic areas can be generally classified into
`two perspectives. One of these is for ‘hard’ technical points relating to the operational software,
`
`Digifonica Technical Review v0.7.doc
`
`page 9 of 35
`
`

`

`TECHNICAL REVIEW FOR DIGIFONICA VOIP SYSTEM
`
`whereas the other is for ‘soft’ topics such as development and delivery processes that are still
`technical in nature, but do not specifically affect the live service.
`
`The split in the topics between ‘hard’ and ‘soft’ areas are summarised in the table below
`
`Review Topic Area
`Documentation
`System Architecture & Design
`Software Platform
`Development Process & Change Control
`Source Code (Core and Web Apps)
`Test Procedures and QA
`System Functionality
`Miscellaneous (tech issues)
`
`Hard
`
`Y
`Y
`
`Y
`
`Y
`
`Soft
`Y
`
`Y
`
`Y
`
`Y
`
`These distinctions are also used in calculated average result figures to provide the reader with an
`additional view on the results, where the ‘hard’ technical areas may be deemed most important.
`
`Digifonica Technical Review v0.7.doc
`
`page 10 of 35
`
`

`

`TECHNICAL REVIEW FOR DIGIFONICA VOIP SYSTEM
`
`4 Review Detail Comments
`This section of the document details the findings of the technical review.
`4.1 Actual Review Process
`Stages 1 and 2 of the review process have now been completed in the UK and Canada, with
`generation of this report being the activity covered in stage 3.
`
`The process covered the areas as defined in the original plan for the review, with more attention paid
`to specific areas where deemed suitable as the review stages progressed.
`
`One change from the plan is that the report has needed to draw a distinction between the Version 1
`and 2 (or Phase 1 and 2) software development projects within Digifonica. This did not affect the
`activities performed, but has led to results being calculated separately for these two stages of
`development. This split corresponds to the historical position of product development, compared to
`the processes and ongoing development activities that are now in place.
`
`4.1.1 Areas Covered By Review
`The initial stage of the review was concerned with understanding to overall system architecture and
`the level of documentation available at that higher level. This involved meetings with Clay Perreault,
`plus access to high level system documentation.
`
`The second stage went into further detail of particular areas of the system, with face-to-face meetings
`and discussions with technical staff in the Digifonica company offices, as well as visits to the hosting
`centres in London and Vancouver to see the node installations currently in use by the system.
`
`This review report summarises both stages of the review, and covers the following points:
`
`System Architecture and Documentation
`(cid:120)
`Core components for call handling - software design and implementation
`(cid:120)
`(cid:120) Web application design and implementation
`(cid:120) General review of source code environment
`(cid:120) Database access methods and design
`Testing processes, tools and reports
`(cid:120)
`Performance testing strategy and benchmark calculation
`(cid:120)
`Software build and deployment facilities
`(cid:120)
`Functionality of VoIP solution as currently implemented
`(cid:120)
`(cid:120) Ongoing development process and planning methodology
`
`Comments covering these points are included under the headings matching those in the initial
`definition of the review process within this document.
`4.2 Calculated Results
`The table below includes figures for ‘completeness’ and ‘surety’ as identified in the review against the
`current ‘Version 1’ position and the planned ‘Version 2’ development, which is currently in progress.
`Averages are also provided for the overall results, plus the split between ‘hard’ and ‘soft’ perspectives.
`
`Topic Area of Review
`
`1. Documentation
`2. System Architecture & Design
`3. Software Platform
`4. Development Process & Change Control
`5a. Source Code (C Core Components)
`5b. Source Code (PHP Web Apps)
`6. Test Procedures and QA
`7. System Functionality
`8. Miscellaneous (tech issues)
`Average percentage figures overall
`Average percentage, ‘hard’ areas
`Average percentage, ‘soft’ areas
`
`Version 2 Position
`Version 1 Position
`% Complete % Surety % Complete % Surety
`45%
`30%
`70%
`85%
`70%
`60%
`90%
`85%
`85%
`80%
`100%
`95%
`40%
`60%
`95%
`92%
`60%
`75%
`80%
`99%
`35%
`30%
`85%
`78%
`15%
`70%
`70%
`85%
`75%
`82%
`88%
`92%
`80%
`80%
`90%
`78%
`56%
`63%
`85%
`88%
`65%
`65%
`89%
`90%
`45%
`60%
`81%
`85%
`
`Digifonica Technical Review v0.7.doc
`
`page 11 of 35
`
`

`

`TECHNICAL REVIEW FOR DIGIFONICA VOIP SYSTEM
`
`These figures should be taken as a guideline, with reference to the detailed comments to identify why
`each area may have a higher or lower figure than may have been expected. For specific details and
`comments on each topic, refer to the subsequent section of this document.
`4.3 Review Topics
`Comments are provided here against the individual review topics, to highlight points that affect the
`review figures listed above.
`
`4.3.1 Documentation
`
`Version 2 Position
`Version 1 Position
`% Complete % Surety % Complete % Surety
`45%
`30%
`70%
`85%
`
`Digifonica provided a large set of documents for the initial stage of the review process (as listed in
`Appendix B). This documentation provided a description of the overall functionality and operation of
`the Digifonica VoIP solution, mostly from a high level.
`
`These documents did appear to be biased more towards an external or sales focus, describing
`features and benefits of the Digifonica software and hardware platform, rather than indicating how
`those features exist within the code base.
`
`From reading this level of documentation, it was not easy to ascertain which features were already
`implemented in the live service, as opposed to those that were able to be added in a future release.
`Being high level documents, technical issues were not covered in depth; this did however mean that
`the documentation is suitable for a broad level of readership in gaining an understanding of the VoIP
`solution and the features and functionality to be supported by the Digifonica service.
`
`During the second stage of the review process, further technical information was obtained from
`informal discussions and code review (see below). This does appear to highlight a lack of detailed
`design documentation at this particular phase of software development. This is something that is
`being addressed for the Version 2 software development process, where activities are moving from a
`small close-knit team with informal methods for information sharing, towards a larger team with more
`formal documented methods and approaches towards development.
`
`The one area which would benefit from further development effort would be the documenting of the
`overall system architecture, with process flows and documented interfaces between components. This
`detail is known by the current development (and management) team, but time could be saved when
`bringing in new team members for development and support if this extra layer of system design were
`documented in a more formal fashion.
`
`Smart421 have included an initial interpretation of the type of design documentation that would be
`preferred to describe aspects of the Digifonica solution. This is shown in a later section of this
`document, to indicate our understanding of the system as presented during the review using informal
`methods (whiteboard diagrams, general discussions, etc).
`
`To complete this topic, some minor points are provided below relating to the documentation that was
`provided for review.
`
`(cid:120) Many of the documents in the initial set, excluding feature plans, seemed to be at only their
`first or second version, mostly having been written quite recently and subject to a single
`revision before release. This appears to show the use of informal design and development
`methods for creation of the initial release of the software, with documents being created ‘after
`the event’. With correct documentation, this is not in itself viewed as a problem, but is viewed
`as worthy of comment; also to point out that more rigorous documentation is being created
`during development Version 2.
`
`(cid:120)
`
`The lack of technical documentation depends on domain knowledge within the team
`environment, which is acceptable whilst the team is small in size. This information should be
`captured and documented for use by a larger future team. This would be improved through
`the use of sequence diagrams showing entry and exit points of