Overview: Create a reliable and successful AIMMS application

This is a checklist to develop a reliable, successful AIMMS application.

  1. Understand the application complexity

    1. Who is your audience and what is the type of purpose? Is your app a study, to be used once? Is your app a strategic app, only to be used now and then? Or is your app an operational app to be used often by a large audience?

    2. Are the tasks that the model needs to perform properly described? For instance, when building a S&OP app, is the demand forecast a given, or can it be operated upon?

    3. Are the tasks that the users need to execute properly described?

  2. Understand the modeling complexity

    1. Which OR techniques are you going to use? (LP, MIP, NLP, MINLP)?

    2. Did you consider doing a literature research to find an efficient formulation?

    3. What are the units of measurement to be used in the application?

  3. Team setup

    Does the team setup cover all the skills and roles related to the project, consider:

    1. Modeling skills

    2. Programming skills

    3. End user design skills

    4. Stake holder role

    5. End user role

    Especially, when all these skills are in one person, that person should avoid being trapped in his own mind and get feedback fast.

  4. Design data management early on

    Design your data management approach. How do you manage your data? Where is input data coming from? Where do you store results or scenarios? Which data is owned by the application to be developed, which data is owned by other applications.

    1. When you use data files (XML, XLSX, CSV, or case files), how do you manage different versions?

    2. When you use an application database, how do you handle structural changes?

  5. Use source code management / version control

    Source code management and version control are essential tools for project management, quality control and collaboration. These allow you to easily and reliably react to your first feedback or collaborate as a team on one application or make intermediate releases.

    You may want to go further and differentiate between Development and Master/Release branches.

    And you may want use a ticketing system integrated with the source code repository.

    Are your design documents part of your source code?

  6. Determine at the start: single-user or multi-user

    Determine how many users and/or roles will collaborate with the same data and same application, concurrently and/or sequentially. This will influence several aspects:

    1. Data management choice (multi-user often requires an application database and concurrent use greatly benefits from CDM),

    2. Need for role and permission differentiation

    3. User-interface page flows and page designs, etc.

    4. Capacity sizing (# concurrent users, solves, peak times)

  7. Estimate early resource requirements

    Early in the development start measuring memory requirements and solve durations. Also find out the likely number of concurrent users, concurrent solves and usage patterns over time (day, week, month, etc.). Together these will drive subscription sizing and, if on-premise, hardware sizing.

  8. Test non-functionals early on

    Start early testing with real-life data set (sizes) to catch performance and scaling challenges. Include early testing on AIMMS PRO or AIMMS Cloud Platform, again to catch potential problems.

  9. Consider automated testing

    Consider developing automated tests, for example using the AIMMS Unit Test library. This will pay off in increased innovation speed and reduced maintenance effort, because you can quickly and accurately re-test models after changes.

  10. Work incrementally with end-user feedback

    Keep your feedback loops short by giving regular demos to end users, starting early in the project. This will increase user/client happiness and reduce project effort and cost. This requires that you develop the user interface and the model concurrently. Maybe even start with the user interface and then build the model underneath.

  11. Consider end-user documentation requirements

    How can each end-user relate his tasks to the features and screens offered by your application?