In Development - Sage Accpac R&D Team Blog

In the Sage ERP Accpac 5.x series of product, all screen definitions were part of the Visual Basic programs that made up each user screen. The only way to get at these screen definitions was to embed the OCX for that screen in a VB program or VBA macro and then manipulate the screen programatically. With Accpac 6.0, we wanted to make many screen customizations way easier. The solution was to separate the screen definition from the User Interface program. In Accpac 6.0 each screen is defined in an XML file that contains all the layout information. This screen can be edited in a Visual Screen Designer that is part of the product, or since XML is just a text file, it can be edited in a standard text or XML editor. For that matter the screen can be generated from another program. The definition of the screen layout file (xsd file) is available and the format is completely open.

In Accpac 5.x, we saved a lot of programming time by binding the individual UI elements to datasources. This meant that an edit control was actually attached to a View field via its properties in the VB form designer. Then the control would be data aware and handle setting its data into the view and retrieving updated data from the View. In this way, no programming was required for most of the forms on the screen. We have exactly the same concept in Sage ERP Accpac 6.x. Only each control is bound to a field with in an SData feed and that SData feed could theoretically come from any Sage application that provides SData feeds or from any other application that has adopted the open SData format. Thus again no programming is required for most fields on the form.

Then we have gone one step further and provided standard actions that can be attached to controls in the layout. In Accpac 5.x you had to code all the logic that happened when a button was pressed. In Accpac 6.x we provide standard actions, so for instance you can attach a save action to the save button which will perform the save operation on the configured SData feed. This way we can develop simple forms with navigation, save, new and delete operations, with no programming. The declarative layout actually produces a complete running program can run with no additional code. Many of the Accpac setup and other simple screens can be developed this way, greatly speeding the development of Accpac 6.x.

The layouts for Accpac 6 are quite different from the screens in Accpac 5.x. For one thing all controls were placed on 5.x screens at specific x,y co-ordinates. In Accpac 6, all layout is handled by browser document object model layout nodes. Nothing is specified in x,y coordinates, you just specify which controls line up and how and then the process is dynamic depending on the length and size of the text. This is a great benefit when translating into languages that take more space like Spanish since the form will automatically adjust to the longer text. When running a right to left language like Arabic, it’s even smart enough to be able to re-arrange all the controls into a right to left ordering. All this is just functionality built into every browser and something we gladly don’t have to worry about.

These are just some of the new things that declarative layouts are bringing to Sage ERP Accpac 6.0A. This will really be a strong and flexible foundation to develop on.

For Sage Accpac ERP 6.0A development we are adopting the Agile Software Development Methodology. Within the Agile world there are several widely used sub-branches, we are using scrum without going all the way to extreme programming (XP).

For previous versions of Accpac we used the waterfall method of software development has been around a long time, and many successful products have been developed using it. However it does have a number of drawbacks:

1. It relies heavily on all the requirements being defined upfront and then complete accurate specs being developed before coding begins. Practically speaking this has turned out to be humanly impossible. Requirements change as market conditions evolve. No one can review a large spec and ensure that something hasn’t been missed, or gone in a bad direction.

2. The handover from programming to QA leads to huge scheduling problems. You can schedule how long to code something (at least relatively) and how long to perform functional tests. But how do you schedule how many bugs will be found? How long to fix those? How long to retest  these? How long QA is delayed because they are blocked by these bugs?

3. Combining 1 and 2, practically speaking the worst design defects are found in QA when it is quite expensive to fix these. Again this tends to be un-sheduleable work and usually is the cause of the biggest product delays.

Agile looks to fix these problems (and many more besides). The idea is to keep units of work manageable without requiring super-human powers. Another idea is that you don’t need the requirements up front, nor do you need the specs up front (if at all). Some of the key ideas:

1. Break down requirements into small easy to manage “user stories”. This makes the requirements more customer focused and really forces functional decomposition right from the beginning. It then lets you prioritize these requirements and tends to limit designer gold plating.

2. All team members are involved for the whole project. There are no hand overs from one group to another. Traditionally these hand overs lead to delays (due to people not being available at the right time), defects due to misunderstandings, and lack of teamwork. With agile the design analyst, programmer, UCD specialist, QA person and product owner are always working together as a team through the whole process.

A lot of the rest of the Agile Development Process is then executing these ideas in a best practices type environment using the experience of previous teams. From the experience of others, leads to the scrum principles:

1. Short fixed length iterations (for use these are 3 weeks).

2. The product is “shippable” quality at the end of every iteration. This goes hand in hand with the idea of continous integration. The product is built everynight complete and automated test scripts are run to ensure nothing is broken.

3. How to break down the user requirements,  and pick the ones to implement in each iteration.

4. How to prioritize the requirements and handle things that go wrong, like too hard user stories, key team members on vacation, etc.

5. Better visibility to all stake holders. Everyone can see the list of user stories and the time estimates associated with them. This allows everyone to know how long something will take and why it will take that long.

Generally many product groups have discovered that Agile Development Process’s are more productive (more features or products are developed), quality is higher and the process is more predictable. Probably the hardest thing with adopting Agile is just to forget all those practices taught in older Software Engineering courses in University and accept the newer methods.