postage and handling accelerator: graduate project...

Postage and Handling Accelerator: Graduate Project Results

Adam Best

GlossaryAccelerator A standalone feature that works as a plug-in set of software functionality.Customization impacts The unique customizations that a client environment contains. Environment The server where the Dynamics AX environment is installed.ERP Enterprise Resource Planning softwareGold Partner Certified Microsoft re-seller. Provides unique customizations.Impact The overall interaction with base Microsoft objects.Junction Solutions A Microsoft partner who builds additional feature sets.Microsoft Dynamics AX The ERP software.Object System objects for development such as Tables, Classes, FormsVertical The Junction Solutions additional framework. This is the original framework

developed by Junction.

IntroductionJunction Solutions provides numerous pieces of functionality for Enterprise Resource Planning

software. Each piece of functionality will be broken down into what Junction defines as an accelerator. This accelerator is a low impact standalone feature. It enables the sale of individual components of the software as opposed to one giant package. This could lead to more sales and more customization for the Junction client base. The accelerator developed in this project is Postage and Handling

With the latest updates to the Microsoft Dynamics base system, Junction Solutions functionality is no longer valid to be upgraded through the traditional path. This causes a key problem in the way Junction delivers their software. Junction can no longer provide a basic upgrade with the next release. This is where the accelerator comes into play.

The reason for the accelerator is to provide the functionality provided in the previous vertical. The Postage and Handling functionality has been chosen as a sample accelerator to help identify guidelines. The motivation for this project is to reduce Junction's overall impact and provide an easily upgradeable feature to adapt to Microsoft's new releases of Dynamics AX.

The challenges involved in the creation of a new feature type such as the accelerator include adapting to a new style of development, defining new integration techniques, handling customization impacts, preventing regressions on base functionality, meeting Microsoft standards, and environmental management. These are what needed to be overcome in order for this project to succeed.

Each of the challenges above was overcome through a series of documentation. The documentation provided helped to resolve any concerns regarding techniques and other impacts. Details about the accomplishment are discussed further in this paper.

Junction as a team decided to evaluate the previous process and find ways to improve their current processes. With this, the team decided to push forward with code refactoring as well as establishing base standards for Impact Analysis as well as the creation of a new Implementation Guide. These documents were created by the developer and reviewed by members of the team.

The developer aimed to successfully create and implement an accelerator. The objective was to provide the functionality while achieving a standalone framework, minimal footprint, ease of implementation, easy verification, a new testing structure, code upgrade to meet new standards, and an upgradeable framework. These goals were met with their own challenges including new integration techniques, customization impacts, regression prevention, and environmental setup and management.

This project taught the developer the importance of planning, establishing a strong framework, and creating evaluation metrics. The lesson learned around planning is there always needs to be a backup plan. This project was estimated with a moderate level of effort. This effort increased as dates were pushed back due to environmental constraints. The next lesson learned consists of the establishment of a strong framework. This lesson not only applies to the code structure, but the overall accelerator process framework. As a developer, many items can elude you in regards to building a strong project definition. The next lesson learned was the process to create evaluation metrics. With each individual project, the evaluation can have numerous levels of measurement. This extends beyond the traditional goals and requirements. These lessons learned were valuable throughout the project and will continue to assist in future accelerator development.

About the CompanyJunction Solutions provides an integrated system that provides industry specific information to

the Food and Beverage industry as well as Distribution and Retail. Their solution was built on Microsoft Dynamics AX focusing specifically in these industries. Their goal was to achieve operational efficiency and drive competitive advantage. This is performed in order to achieve a well flowing operations management for their customers. The software Junction Solutions provides enables organizations to work effectively, manage change, and compete globally.

Junction Solutions is broken up into multiple segments in regards to the software they provide. In the proposed accelerator, the two teams involved will be the Retail team as well as the Food and Beverage team. Each department focuses on functionality that will meet their client's needs. This can range from running multi-channel retail pieces such as customer service management to dairy inventory for a Food and Beverage customer.

The development team, support team, and consulting team will all be stakeholders in the accelerators. The development team will perform the initial implementation of the accelerators. Therefore their interest lies in the process performed and the measures of success. This project will provide a base guideline for future accelerator development. The support team will be required to

maintain the functionality of the accelerators. Their interest lies in the documentation and code commenting. When a client calls up and requests assistance for any reason, they need to be able to quickly analyze and evaluate what was implemented and how it should perform. Lastly the consultants will be the main implementers. The consultants are on site at the clients and modify the client's system to meet the requirements as well as to properly implement all requested functionality.

This project has provided a strong foundation as a guideline for future accelerator development. This will help with the timeline, organization, and documentation needed in order for an accelerator to be completed to the fullest extent. The organization is important as this is the defined categorization that other implementations will follow. Test cases, documentation, and development efforts need to be clearly stated. Next is the timeline. This timeline will be a basis for future estimates. The development and organizational efforts in this project have been recorded in the project timeline. Finally, the documentation provided assists in the process replication.

About the SoftwareMicrosoft Dynamics AX is an Enterprise Resource Planning (ERP) solution. This solution is

designed for midsize and Tier-1 organizations. The solution is Powerful, Agile, and Simple. The base Microsoft Dynamics Ax solution will handle capabilities such as:

Financial management Human capital management Manufacturing Supply chain management Project management and accounting Retail Business intelligence and reporting

These capabilities are designed to help an enterprise handle all operational and organizational processes. Each component contains the essentials for a business to operate.

With the advanced functionality of Microsoft Dynamics, an out of the box solution can only provide so much. Junction Solutions has worked to fill these gaps. Junction provides the Microsoft Dynamics solutions with their own vertical containing the Retail and Food and Beverage Functionality. This has assisted organizations such as:

H-E-B Grocery Chain Peets Coffee & Tea Cable Shopping Network Simon Pearce Miles Kimball Century Marital Arts Royal Canadian Mint Gardener's Supply Company

Each of these organization required specific modifications to each piece of functionality to meet their business processes. This is where the ease of implementation becomes a major factor.

The software that Junction Solutions provides is implemented into a client's environment and then modified by consultants. This has become difficult when performing the initial implementation as well as any software upgrades.

Developer RoleThe developer's role within Junction Solutions is as a primary contributor for the new

accelerator functionality that Junction Solutions aims to achieve. The developer's previous experience consists of development on the Junction Solutions' vertical. The vertical was the entire software package including the entire set of features. This experience provides a step in the right direction as the old process of implementation as well as the code language is well known.

Throughout the course of this project, the developer has provided a Business requirements document, Technical design document, Impact analysis document, Implementation guide and test cases for the Postage and Handling Accelerator.

By providing these documents, the developer established an understanding of the overall accelerator process and what will be required in order for an accelerator to have success. The documents provided also assisted in the requirements for future accelerator development.

Background

Software HistoryIn past development Junction Solutions has freely implemented features into the Microsoft

Dynamics software. Junction Solutions has provided their solutions embedded into the software purchased by the client. Development efforts were strictly to implement the project and achieve the required functionality. The footprint of Junction within the Dynamics environment was never a consideration. This resulted in difficult implementation at new client sites as well as software upgrade challenges.

With the Junction Solutions code deeply integrated into the base environments, it became difficult to identify the specifics to a particular feature. Documentation has been lost along the way and the original developers have moved on. As Junction looks to move onto the latest and greatest of the base Microsoft Dynamics AX software, it came time to reconsider the implementation and footprint that Junction has within Dynamics.

Project DetailsThe impacted areas of the Postage and Handling Accelerator are some of the core components

of the Microsoft Dynamics ERP system. This consists of the sales order functionality, customer promotions, discounts, invoicing, as well as order calculations. This type of integration is what the company is doing to try and reduce the overall impact.

This is why the Postage and Handling feature became a starting feature for the new accelerator concept. Previously the functionality required that the user be able to connect postage and handling rates to offer setup. This could provide the client with solutions such as free shipping, discounted shipping, flat rate, et cetera. The offer would then be provided within an order or tied to a specific customer. When that offer or customer was used, the new postage and handling rate would apply. This would be represented in an order recap screen. This was the basic idea of the postage and handling functionality. The new requirements will be provided in the Business Requirements Document.

The impact of the functionality can be seen in both the physical and logical model of the previous integration. The physical model as shown in Appendix A shows the base objects in white boxes. The orange boxes are Junction objects. The logical model shown in Appendix B displays a simplified version of the impact with reverse color coding.

You can see the impact on a table level by viewing the SalesTable on the physical model for example.

On the SalesTable, the fields jsPostageGroupId and jsPostageSchedule are Junction fields on a base table. This causes a problem for numerous reasons. By adding fields to this table, Junction has increased the difficulty required for upgrade. When Microsoft releases an upgraded version of Dynamics AX, it is the developer's job to properly merge all areas. While an added field may not seem like a large impact, the bigger impact is on system classes that are based around these tables such as AxSalesTable and SalesSalesOrder_SalesTable for the SalesTable. The overlap results in the developer manually evaluating those objects for any impact or overlap to ensure that no upgrade code is missed. To this day, Junction is locating omitted code or incorrect functionality in smaller features.

Additional concerns revolving this functionality is the removal and refactoring of combined features. Postage and Handling utilized offers and source codes. In newer versions, this functionality will not be obtainable as some has been removed and some has been re-factored. By creating the standalone framework, the functionality now works without the integration into the newer pieces.

GoalsWith the new accelerator concept, the goals are driven around the future success of additional

accelerators. These goals consisted of the following:

Standalone framework Minimal footprint

Ease of implementation Easily verifiable Testing structure to verify new functionality Testing structure to verify base functionality Meet Microsoft standards Establish functionality beneficial to Retail and Food & Beverage departments. Structured framework capable of upgrade

Each of the goals above was taken into consideration during this development of the Postage and Handling Accelerator. The achieved goals can be reviewed in the Goal Accomplishment section further in this paper.

Utilizing these goals as driving points for the project truly helped define and guide the entire project management process. The majority of the goals worked hand in hand. The standalone framework helped to reduce the footprint as well as create a framework capable of an upgrade. The reduced footprint helped to make implementation easier. The testing structures helped to make the accelerator easily verifiable and the remainder of the goals remained standalone.

Challenges Throughout this project, a few challenges that were predicted occurred. While some of these

challenges were easier to overcome than others, each challenge affected the desired goals for the Postage and Handling Accelerator.

The original challenges predicted are shown below:

New style of development New integration techniques Customization impacts Prevent regressions of existing functionality Meeting Microsoft standards Meeting requirements for dual departments Environmental setup and management

Each of these challenges had their valid concerns, but not all became issues. Those that did not become major issues were Customization impacts and meeting Microsoft standards. These modifications were overcome through the achievement of primary goals. The challenges that did occur are described below.

The standalone framework challenge was based around the determining factor of making the feature standalone or to utilize the existing extension framework. Even though the feature was small in size, creating a standalone framework of classes and tables came significantly easily. Once the impact was removed and placed into a new table, the refactoring of the code was the most difficult part of achieving this goal.

By creating this standalone framework, the analysis below documents the overall percentage reduction in Junction's impact. The challenge involved for the minimal footprint was to research and analyze each level of impact and determine whether or not the feature should have a footprint in that specific functionality. The research efforts for this were substantial.

The verification process was one of the larger challenges that had a major impact on the project. Due to environmental issues, the option of providing unit tests to assess coverage as well as validity in integration was unavailable. The environment released by Microsoft was a trimmed down version without the tools required to create and perform these tests. This reduced the amount of verification we could perform.

Another larger impact challenge was with the departmental satisfaction from multiple departments. While the accelerator has been written to be utilized for each department, the overall concern and involvement of external departments was quickly diminished due to company reorganization changes.

Finally, the largest impact on the project success was the environment creation and management. Due to the company reorganization mentioned above, the individuals invested and their resources completely changed. Another setback with the environments was the release of CTP5 for Microsoft's Dynamics AX 2012 R3. This version was the base environment for the new accelerator. Due to Microsoft delays, this was released late. Once released, the issue became locating and achieving permission to use the resources for a proper environment.

Measuring for SuccessWith a new feature pack style of functionality, it is critical that evaluation methods and metrics

are established in order to properly measure the success of the accelerator project. Taking a look back, the project will be measured on the goals that were accomplished and the challenges overcome. Some keys to measuring success is looking at the reduction of impact, the code review to assure best practices were met, the performance impact, and the overall test case coverage.

The reduction of impact will be measured on the overall reduction percentage from the original object count to the new object count. While this task can be difficult to measure, it is beneficial to look at the overall reduction based on percentages. Individual integrations will be taken into account and evaluated manually. The percentage is calculated by taking the total impacted base objects post development and dividing it by the original base impact count.

The next measure of success is the code refactoring. Code quality can be difficult to measure. The process used to evaluate the quality of success is performed through an automated code analyzer. This analyzer will detect common best practice mistakes such as Invalid comments, header formatting, Hungarian notation, Junction defect tags, and incorrect Dynamics Select statements. Each of these issues in the code is a major part of this project. The refactoring of this code results in all Junction code to become more efficient, properly documented, and to meet Microsoft standards. This allows Junction to maintain their Gold Partner certification with Microsoft.

The third success metric is performance testing. Performance testing is measured on the amount of database calls and seconds increased when calling the same functionality. This measurement is performed by the Microsoft Dynamics AX Trace Parser. This tool begins a trace of the systems and tracks all of the calls through the back end while you perform the front end testing. Once the front end testing has been completed, then the developer goes back and stops the trace. The system then generates a file that can be reviewed. This file contains information regarding the RPC calls and total database calls. Each call is documented in the time it took to execute as well. The reason for running the performance check is to ensure that there are no major performance impacts for customers that will be running large amounts of records with your functionality. A minor decrease in performance is expected, but this needs to be maintained within reason.

Finally there is the overall test case coverage. This project required test cases to be written in order to validate the requested functionality. These test cases cover the foundation functionality for the Postage and Handling Accelerator. This measure for success is a pass or fail evaluation. If the test case fails, it is up to the developer to resolve any outstanding issues. If the test case passes, the result needs to be documented for the time and date that the user verified the functionality. This measure of success can also be transferred to the Implementation Guide for the verification process.

Each of these measures of success dictates the project's overall success. They are units of measure that determine how successful the project was as well as provide evaluation metrics for future accelerators. By evaluating the impact reduction, code re-factor, performance, and test case coverage, it provides a strong foundation for measures of success.

Project ResultsWith the defined measures of success, the overall project can be viewed as successful. This can

be measured utilizing the success metrics defined above. This section will provide the results for the reduction of impact, code upgrade, performance impact, and the overall test case coverage.

Reduced Impact ResultsThe original impact from the Postage and Handling functionality was significant. This consisted

of a total of thirty-six base objects. In order to achieve the project goal of reduction of impact, these needed to be decreased. The project successfully achieved this goal.

As documented in the Impact Analysis, the original impact for Postage and Handling was quite large. The reduction of impact per object can be seen below:

Type Original Base Impact Objects Count

New Base Impact Object Count

Overall reduction

Tables 12 0 100%Classes 16 5 68.75%Forms 3 3 0%Enumerations 1 0 100%Queries 3 0 100%Maps 1 0 100%

As demonstrated in the table above, the overall reduction of impact was severely beneficial. This is due to the complete reduction of the table impact. Without impacting base tables, the developer was able to remove all unnecessary ties to that field. The overall reduction was a 77.78% reduction from the original form. Achieving such a high level reduction proves for future accelerators that significant reductions can be achieved.

Automated Code Review ResultsThe code re-factor evaluation was measured through the automated code analyzer. The code

analyzer ran to detect common best practices. These best practices errors were a main goal throughout this project. The automation of the analysis helped save time and efforts for this particular step.

The code analyzer is driven off of a single option to check the selected object. This is called through the jsCheckNode functionality. Within this functionality, the code is assessed and identified for any faults. The faults that are detected are listed and described below:

Invalid commentso Old style headers beginning with // instead of the new /// style. o Blank comment lineso Improperly formatted lineso Invalid

o Valid

Code cleanupo Change method parameters formatting.

o Incorrect style of commento Incorrect indentations

Hungarian notationo Rename all variable names such as tSalesTable for the SalesTable table and oListEnum

for the object ListEnum.

o Existing defect tags.

o Junction tags such as F#### and D#### to mark defects and feature functionality. Invalid select statements

"Select *"

The code analyzer searches for best practices, but particular steps such as the detection of existing defect tags, and parameter settings, are detected to assist in maintaining visually appealing code lines. The easier the code is to read, the more efficiently it can be evaluated when a new user is reading through.

The results for the check node at the end can be seen below. If the infolog doesn't contain any warning and only contains the object and "Check complete", it has successfully passed the automated code review. The first run for the Class jsPostageLine can be seen below. For a complete list, please see the CheckNode.xlsx file.

Warning

Check Node Results:\jsPostageLine\Method: addToRecordSortedList Path: \Classes\jsPostageLine\addToRecordSortedList

The first word in the summary node, 'Add', doesn't end with an 's'.

Warning

Check Node Results:\jsPostageLine\Method: addToRecordSortedList Path: \Classes\jsPostageLine\addToRecordSortedList

Method header node 'param' contains no text.

Warning

Check Node Results:\jsPostageLine\Method: includeInPostage Path: \Classes\jsPostageLine\includeInPostage

Method header node 'summary' doesn't end with a period.

Warning

Check Node Results:\jsPostageLine\Method: includeInPostage Path: \Classes\jsPostageLine\includeInPostage

Method header node 'returns' contains no text.

Warning

Check Node Results:\jsPostageLine\Method: includeInSurcharge Path: \Classes\jsPostageLine\includeInSurcharge

Method contains a //FXXXX comment.

Warning


Method header node 'summary' doesn't end with a period.

Warning



Warning

Check Node Results:\jsPostageLine\Method: initRecordSortedList Path: \Classes\jsPostageLine\initRecordSortedList

The first word in the summary node, 'Initialize', doesn't end with an 's'.

Warning

Check Node Results:\jsPostageLine\Method: initRecordSortedList Path: \Classes\jsPostageLine\initRecordSortedList


Info Check Node Results:\jsPostageLine Check complete.

In these results, you can see that for the jsPostageLine class, there were nine warnings. These ranged anywhere from the code cleanup pieces, such as the FXXXX comments to the header comment clean up. At the bottom is the "Check complete" info message.

If you look below, you can then see that not only has the jsPostageLine been cleaned up, but all other classes involved in this project as well. This can be seen with the info log only displaying the Check complete message. This identifies that no additional errors were found.

Final Results Info Check Node Results:\jsCachePostage Check complete. Info Check Node Results:\jsPostageGroup Check complete. Info Check Node Results:\jsPostageGroup_Calc Check complete. Info Check Node Results:\jsPostageGroup_Current Check complete. Info Check Node Results:\jsPostageGroup_Invoiced Check complete. Info Check Node Results:\jsPostageLine Check complete. Info Check Node Results:\jsPostageLine_CustInvoice Check complete. Info Check Node Results:\jsPostageLine_Quotation Check complete. Info Check Node Results:\jsPostageLine_Sales Check complete. Info Check Node Results:\jsPostageLine_SalesParm Check complete. Info Check Node Results:\jsPostageMethod Check complete. Info Check Node Results:\jsPostageMethod_AmntPercent Check complete. Info Check Node Results:\jsPostageMethod_AmountCheck complete. Info Check Node Results:\jsPostageMethod_Free Check complete. Info Check Node Results:\jsPostageMethod_Percent Check complete. Info Check Node Results:\jsPostageMethod_WeightZone Check complete. Info Check Node Results:\jsPostageOrder Check complete. Info Check Node Results:\jsPostageOrder_Quotation Check complete. Info Check Node Results:\jsPostageOrder_Sales Check complete. Info Check Node Results:\jsPostageOrder_SalesReturn Check complete. Info Check Node Results:\jsRateChartConfigure Check complete.

Each info message stating the object and "Check complete" identifies a passing scenario. This was a primary goal for this particular accelerator.

Performance Impact ResultsThe performance impact results are shown through a series of RPC calls, database calls, and

inclusive and exclusive run times. The Base functionality performance tracing can be seen below.

As shown in the screenshot above, the base numbers of server (RPC) calls are documented. The breakdown can be seen in the Performance analysis document attached with this accelerator. The overall RPC count is 584. The accelerator functionality performance tracing can be seen below.

The accelerator RPC count increased to 588 from 584 for the top calls. Where some areas decreased, others increased. The main increase can be seen for the SalesTableForm::MCRShowOrderRecap. This increase was expected as it is a prime area of impact. When the recap form is loaded, it is required that that postage functionality is called. The overall time remained acceptable. This implementation can be viewed as a success with such a minimal performance impact.

Further results can be gathered from the Performance compare document. This document shows both the entire Base trace as well as the entire accelerator trace.

Test CoverageThe Postage and Handling Accelerator was covered through a series of test cases. These test

cases include the following and are included in the files provided for the implementation. The project has passed the required test cases listed below:

New Functionality coverageo Posting and handling fee calculation based on fixed amount setupo Posting and handling fee calculation based on unqualified range breakso Posting and handling fee calculation based on qualified range breakso Posting and handling fee grouped by mode of delivery

o Posting and handling fee calculation on percentage basiso Posting and handling fee when type is select as 'Free'o Posting and handling fee calculation using with Weight/Zone logic

Base Functionality Coverageo Sales order entryo Delivery mode entryo Markup creation

Each of the new functionality test cases are designed to handle the required functions from the BRD. The base functionality provides simple coverage to ensure key areas are not broken due to improper implementation.

Accomplishments

Goal AccomplishmentThe goals documented above are detailed below with their accomplishments. These

accomplishments assisted in the functional and technical success of the project.

In the Postage and Handling Accelerator, the standalone framework was easily achievable. By removing the postage fields from the base system tables, it allowed for postage to be eliminated from a large portion of the original impact. The removal resulted in the reduction of postage on extension classes for the base tables. This now allows for the table to be driven on its own framework and any connection regarding tables or classes can be added to the now existing postage framework.

The new framework allowed for a minimal footprint. The footprint was reduced through the postage removal on all of the extension classes. This also allowed for there to be no involvement in base System tables. This achievement is critical as it reduces the potential for out of sync data sources on forms.

The ease of implementation has been evaluated by a set of developers. They analyzed the implementation document and estimated their ability to successfully import the Postage and Handling Accelerator into a new environment as well as an existing environment. The results of the poll can be seen below.

Developers questioned: 4 Average estimated time: 1 Hour 30 minutes Average level of difficulty (1-5 scale): 2 - Easy Main concern: validation

Each of the developers found the document o be straight forward. Their main concern consisted of the validation stage. They were looking for more automated processes to validate their work. Aside from this concern, the poll helped determine that the layout and steps required will be beneficial for future accelerators.

Once the accelerator has been fully implemented, the developer needs to go through and follow the next implementation guide section which will direct the developer to the test cases to properly test the new functionality.

Secondary AccomplishmentsThis project resulted in a lot of key accomplishments. Those extended beyond the project goals

and helped establish the new accelerator process. This process was created based on the scenarios that occurred during the project timeline.

Assisted in the accelerator Development Process document.o Validated the accelerator process

Created a standardized Implementation Guide. Created a standardized Impact Analysis document.

By developing an accelerator first hand, the steps and challenges that were run across helped to define this new process for future utilization.

The process begins by the Requestor defining the work. This includes the creation of feature details, the overall feature, document requirements, and feature requirements. Once all of these details have been defines, the Project manager reviews these details. Here is where the project planning is performed. From there the architect (developer) will take the requirements and the planning and create the accelerator while cycling through the approval stage. This process is in the final stages of approval. The Postage and Handling Accelerator did not follow this process, but based on experience and estimation efforts, this process would have been beneficial.

Overcoming ChallengesThis project took place ahead of its designed time. By beginning this project prior to the release

of an environment and no full plan of action established, it caused some unforeseen challenges.

Unforeseen ChallengesWhile some challenges were foreseen, many challenges arose throughout the course of this

project that caused great difficulty and threatened the completion of the overall goals. These challenges consisted in the following:

Change in overall management Environment release delays Lack of environmental resources Lack of company commitment

Each of these challenges were overcome but with setbacks. Initially there was the change in the overall management of the project. Towards the beginning, the main manager was no longer with the company. This caused a major impact as the manager was knowledgeable in the project plan. The requirements and design were to be requested and evaluated by this individual.

The second challenge that occurred was the delay in the Microsoft Dynamics R3 cumulative release. This release contained the latest code without Junction Solutions' vertical. This step was critical as it contained all of the refactoring that was required for the Developer to properly integrate into a new environment with minimal impact. The delay in this release set back development.

This was the lack of environmental resources. This set back the development efforts even further. With the change in management, the environmental resources were re-allocated to a new department. The process of obtaining an environment as soon as possible became a daunting task. It was with the help of a Director that an environment was available for a temporary period of time.

Finally there was a lack of company commitment. The lack of commitment resulted in minimal requirements and an overall lack of validation. The developer was required to develop, define, and validate the entire project. This placed a setback on the overall timeline as it increased the original quoted amount of work.

ConclusionOverall, the project creation for the Postage and Handling Accelerator was a success. This

project not only helped to accomplish a solution for their new upgrade problem, but provided a solid foundation for future development. As Microsoft continues to upgrade their environment, it is up to Junction to adapt as well. Junction adapted with the creation of the accelerator concept. This project success was through the accomplishment of goals and the challenges that were overcome.

The goals accomplished include the creation of a standalone framework, minimal footprint into the base environment, the ease of implementation, easy verification, new testing structures, code re-factoring, and the creation of an upgradeable framework. Each of these goals contributed to the

guidelines for an accelerator. The documentation developed and processes learned were major factors for success.

This project was met with a series of challenges. The challenges throughout this project included meeting a new style of development, finding new integration techniques, overcoming customization impacts, prevention of regression issues, and the environmental setup and management. Each of these was overcome by accomplishing the goals defined.

While the project successfully met the goals, the accelerator was primarily measured on the newly defined metrics. The reduced impact, automated code review, performance impact, and test coverage metrics were created and defined to properly determine the success level of the project. This also provided the guideline for future works.

With the metrics in place, the actual results were verified showing a 77% change in the impact reduction. This decreased the footprint while only increasing performance by a small amount. With the code review process, the newly integrated code met Microsoft best practices and improved the overall code quality.

All of this was achieved through challenges, as well as some unforeseen challenges such as change in management, environmental release delays, lack of environmental resources, and the lack of company commitment. These caused huge impacts on the outcome and threatened the overall project success.

Throughout the accomplishments, challenges, and documentation, this project truly helped to define the future of Junction Solutions Accelerators. The new standards defined and processed evaluated will guide future developer's the ability to quickly and effectively build an accelerator.

ReferencesJunction Solutions. (2012). About Us. Retrieved from JunctionSolutions.com: http://www.junctionsolutions.com/about-us/overview/

Microsoft. (2012). Best Practices for Microsoft Dynamics AX Development [AX 2012]. Retrieved from http://msdn.microsoft.com/en-us/library/aa658028.aspx

Microsoft. (n.d.). Microsoft.com. Retrieved from Best Practices: XML Documentation [AX 2012]: http://msdn.microsoft.com/en-us/library/cc641745.aspx

Microsoft. (2012). Microsoft.com. Retrieved from X++ Coding Standards [AX 2012]: http://msdn.microsoft.com/en-us/library/aa855488.aspx

Appendix A

Appendix B

postage and handling accelerator: graduate project...

Documents