View source | View content page | Page history | Printable version   

Projects:Modularity/ProjectPlan

Iterations

The Modularity project has been split into five sequential iterations each of them including tasks assigned to different developers and a set of test cases. Third and fifth iterations will be merged to trunk.

Iteration Description Test cases Merge to trunk
1 Setup all infrastructure for module content except reference data. Packs and industry template are not supported at this point. Implement the build process -including database creation- of an instance with installed modules. Implement the update database process when new modules are installed or applied modules are updated or uninstalled. Have a clear vision and definition of the whole project Create from OB UI at least three modules. Check that only "in development" modules are available to assign to AD components. Add to these modules at least one AD component of every type (a table, a column in a not owned table, a window, a tab in a not owned window, a field in a not owned tab, ...). Describe dependencies between these modules and core. At least one new module should depend on the other ones. Get the list of licenses that a module can use -from Paolo- and create that list in the AD. Add to these module software resource of every type (jasper reports, java code, jar library, javascript, css, ...). Add also -manually- db schema objects of every type to these modules. Create the database using dbSourceManager from the description in installed modules. Update a module and update the database. Remove a module and update the database. Build the system with the three modules installed and check that everything works fine (at database and application level). Save the module descriptions to be used in future tests. No
2 Modify export utility in DB source manager to take into account modules. Implement the central repository services. First version of the Module Manager Console (MMC). Export/import tool for standard reference data ready to be used in module installation and initial client setup. Using the instance installed in the previous test case, export it -marking modules in development- using dbSourceManager and compare it with the manual code used to generate it. Add additional changes at database level for every schema object type (table, column, index, constraint, trigger, stored procedure, ...) and export again. Get the exported files in modules and manually copy them to a clean instance and build the system to check that it apply the content in those modules. Register those modules in the Central Repository and publish them. See the installed modules and detailed information of each of them from the MMC. Test the export/import tool and prepare a reference data set to be used in modules (Spanish taxes). No
3 Third version of MMC: implement the search and install modules and apply them to the instance, so it should be possible to install and uninstall modules from the OB UI. Module developers guide ready to be used. Initial client setup modified to support modules. First steps in the tool to generate the standard configuration script. Material to be prepared before doing the real user test:
  • Modules with all different types of content. It would be perfect if they were real modules. Ask localization team and consulting for help (TBD)

From OB UI: install a fresh Openbravo ERP instance. Using the MMC install modules in different combinations (one by one, all together, with dependencies not satisfied, uninstall, ...) and check the system always works consistently. Apply reference data to clients by Initial Client setup and Reference data loader. Update those data using the update tool. Ask to a senior consultant in consulting unit to build some modules using the Developers guide.

Yes
4 Module manager console supports packs and Industry templates. It also allows to update installed modules. The tool to generate the configuration script is ready to be used (and tested :-). Initial Organization Setup ready to be used (and tested :-). Material to be prepared before doing the test:
  • Spanish localization pack and a theoretical Industry Template (tight to prepare a real one): ask localization team and consulting for help (TBD).

Test: install the Spanish localization pack and check. Uninstall and check. Install again. Do some changes in application dictionary and database objects. Get the configuration script for those changes. Include the configuration script in the theoretical Industry Template (Spanish localization pack + those changes). Install the Industry Template in a clean instance and check. Perform some customization on top of that and export. Update a module in the Industry Template and update the instance.

No
5 Project completion. MMC supports all types of modules and content, including reference data. The tool to migrate old Openbravo ERP instances to the new modular paradigm (2.50) is ready to be tested. Initial client setup and loading mechanisms can be customized from modules using "adaptors". There is a tool to load and update data at Organization level from modules. Material to be prepared: collect all modules, packs and Industry Templates form previous tests (suggestion: QA should use a different set based on the ones developed by consulting to ensure maximum coverage in the testing processes).
  • For developers: following the developers guide create a module for every type of content. Create a pack and an Industry Template. Register and publish them. Publish a new version with some modifications.
  • For final users: from OB UI: install, uninstall and update a module/pack and Industry Template. Test modules for every type of content (ad metadata, all type of sw resources, all type of reference data). Execute the initial client setup in an instance with modules including reference data installed. Pick some of them from list and apply. Execute the initial organization setup in an instance with modules including reference data installed. Pick some of them from the list and apply. At a later stage apply other modules to the clients and organizations created. Update the modules and update the reference data
Yes

Detailed plan

Sub-project Task Responsible Estimated effort (days) Iteration Spec Build Test Test cases Comments
1. AD Module structure 1.1. Create module structure in application dictionary ALO 1 1 Complete Complete N/A
1. AD Module structure 1.2. Assign AD components to modules: include a mandatory field pointing to the module they are assigned to ALO 1 1 Complete Complete N/A
1. AD Module structure 1.3. Complete module structure in AD with all remaining details ALO 1 4 2 Oct Complete N/A
1. AD Module structure 1.4. Add "registration process" to module window ALO 0.5 5 Complete Complete
1. AD Module structure 1.5. Validate that modules that are not in development are not modified. Do it with triggers. ALO 0.5 5 N/A Complete
1. AD Module structure 1.6. Add to system a check to allow modifications, when this check is set a new template should be created. Additionally, create a window for ad_system table to operate this. ALO 0.5 7
1. AD Module structure 1.7. Prevent some modifications (name, package, db_prefix...) for a module once it is registered. ALO 0.5 6 Complete
2. Build process 2.1.1 Create structure: load the whole structure from xml files and persist it in DB. It does not take into account partial elements (columns,indexes...) nor configuration script AMO 1 1 N/A Complete Complete test-db1: A module made of several new db objects (a table, a function, a trigger and a view), with sourcedata
2. Build process 2.1.2 Create structure: load the whole structure from xml files and persist it in DB. Take into account configuration scripts AMO 1 5 N/A Complete
2. Build process 2.1.3 Create structure: load the whole structure from xml files and persist it in DB. Take into account partial elements (columns,indexes...) AMO 1 1 N/A Complete Complete test-db1, extended with additions to a table (columns, unique constraints, foreign keys, check constraints)
2. Build process 2.2. Update structure: read xml model and compare with db one to update it AMO 1 1 N/A Complete Complete test-db1
2. Build process 2.3. Modify build.xml to take into account resources (for compilation, translation...) ALO 2 1 Complete Complete Complete test1: includes a report with html, xml, java, xsql and jrxml files.
2. Build process 2.4. Modify ODE to manage these resources (ensure packaging is correct, .classpath, ...) ALO 2 1 Complete Complete Complete test1
2. Build process 2.5. Create a process to export an installed module as an obx file ALO 1 3 N/A Complete N/A
2. Build process 2.6. Export process should export all the objects needed by the module (data sources, reference data...). In the exportation process for packs and templates the includes modules should also be exported as independent obx files. ALO 1 6* Complete
2. Build process 2.7. Create a user interface for exporting configuration scripts ALO 1 7*


3. Export process 3.0. Define how to describe the elements that are considered source data. Take into account if they are linked to modules ICI 1 1 Complete N/A N/A
3. Export process 3.1. Export DB objects: Create object filters based on module name and export following this filters. These filters could be designed as pairs of prefix and path. In case AD information about module and physical name do not match show a warning AMO 3 2 N/A Complete Complete test-db1, with added AD_MODULE entry.
3. Export process 3.2. Define Core dataset ICI 1 2 Complete Oct 1st Oct 1st
3. Export process 3.3. Define which elements could go to the configuration script ICI 1 2 Complete Oct 1st Oct 1st
4. Reference data 4.1. Complete technical design on reference data ICI 1 2 Oct 1st N/A N/A
4. Reference data 4.2. Export/import tool for standard reference data MTA 5 2
4. Reference data 4.3. Automate at installation time the loading of other reference data included in installed modules (translations) ALO 1 5 Complete Complete
4. Reference data 4.4. Modify Initial Client Setup UI to load reference data included in installed modules. Allow the user to optionally load these data. All the backend processes related to modules are mocked implementations EAR 4 1 N/A Complete N/A
4. Reference data 4.5. Create the UI of a process to update reference data in clients and organizations from modules. All the backend processes related to modules are mocked implementations EAR 1 2 N/A 10th Oct N/A
4. Reference data 4.6. Create an Initial Organization Setup to load reference data included in installed modules. Allow the user to optionally load these data EAR 5 4 N/A Complete N/A
4. Reference data 4.7. Implement in real the backend processes related to modules (replacing mocked implementations) EAR 3 3 N/A 17th Oct 17th Oct
4. Reference data 4.8. Create a process to update reference data in organizations from modules EAR 2 5 N/A 17th Oct 17th Oct
4. Reference data 4.9. Support localization team in the development of reference data stuff ALO 1 5 N/A N/A N/A
4. Reference data 4.10. Create DataSets model (Tables and windows). GGI 1 2 Complete Complete N/A
5. Customize loading mechanisms 5.1. Hooks for Initial client setup and import loading processes. Eg. How to change the list of document types loaded in a client through a module? It should support adding new document types but also modify the ones loaded in the standard initial client setup MTA 3 5
6. Central repository 6.1 Define infrastructure and services ICI 1 1 Complete N/A N/A
6. Central repository 6.2 Setup a reliable environment (share with heartbeat?) eProjects 1 2 Complete N/A N/A
6. Central repository 6.3 Implement module registration, publishing, updating and querying services GGI 9 2 Complete Complete Complete
7. XML structure for packs 7.1 Define xml structure for packs and industry templates ICI 1 3 Oct 2nd N/A N/A
8. Configuration script generator 8.1. Define elements included in the script (clean, dirty, useless). Define how to deal with reference data -if needed-. ICI 1 1 Complete N/A N/A
3. Export process 3.2 Export AD elements using the DAL objects AMO 2 3 N/A Complete The task is complete, but it is not used yet, as it needs a defined Core dataset.
8. Configuration script generator 8.3. Read the whole structure from DB and XML and compare both models (take into account that DataColumnChange has to be modified to preserve the entire row) AMO 5 3 N/A Complete
8. Configuration script generator 8.5. Define a XML structure for data modifications and prepare DBSM to export differences in data AMO 4 4 N/A Complete
8.6. Change the way database data is updated, so that only specific changes are applied to the database, instead of deleting and inserting everything. AMO 2 N/A Complete
Properly manage audit info AMO 2 5 N/A Complete Complete
9. Migration process for current ob instances 9.1. Define process to ensure that current ob instances smoothly migrate to the new paradigm ICI 1 3 Oct 3rd N/A N/A
9. Migration process for current ob instances 9.2. Export data differences: Export modules and load and compare DB and xml files, use the filter for the comparison AMO 2 5 N/A Complete
9. Migration process for current ob instances 9.3. Export model differences: define a XML structure for all the possible (41) modifications and export them GGI 10 4 22 Oct
9. Migration process for current ob instances 9.4. Export other resources (for dirty script) GGI 5 5 29 Oct
10. Module manager console 10.1. Define look&feel and UI for the window ICI 1 1 Complete N/A N/A
10. Module manager console 10.2. First version: see installed modules in a tree structure, properties of a given module (full description, license, author, ...) ALO 2 2 Complete Complete N/A Keyboard navigation for tree component pending (DBA)
10. Module manager console 10.3. Second version: apply installed modules (compile and deploy) ALO 3 3 Complete Complete N/A
10. Module manager console 10.4. Third version: search and install modules (without reference data), including remote and local sites to provide the module. Keep installation history ALO 5 3 Complete Complete 1 Oct Depends on 6.1, 6.2 and 6.3
10. Module manager console 10.5. Fourth version: search for updates (module by module, all together) ALO 1 4 Complete Complete Depends on 6.1, 6.2, 6.3
10. Module manager console 10.6. Fifth version: Support for packs and industry templates ALO 2 4 Complete Complete
10. Module manager console 10.7. Sixth version: Support for reference data. Module manager console will only extract the info in the correct directory, after that in the Apply process the reference data for system client is loaded. ALO 1 5 Complete Complete
10. Module manager console 10.8. Improve tree UI adding dotted lines ALO 1 5 Complete Complete N/A Nice to have
10. Module manager console 10.9. Improve tree UI adding scroll to div in order to be able to go directly to the update description. ALO 1 5 Complete Complete N/A Nice to have
10. Module manager console 10.10. Improve tree UI propagating the update icon to the parent nodes. ALO 1 7 Complete Nice to have
11. Developer's guide 11.1. Write documentation to describe how to develop a module, pack and Industry template ICI 5 3
12. Collaterals 12.1. Modify the translation process (export/import) to have into account modules (translations should be done at module level) GGI 1 1 N/A Complete Complete test1: export language from a module. test2: export language from a table with a parent table. test3: import language.
12. Collaterals 12.2. Allow modules to implement new web services ALO 2 6 Complete
12. Collaterals 12.3. Allow modules to extend web.xml file. This extension should be done using a new type of Model_ojbect for non-servlet objects, additionally it might be required to add the ad_module_id column to ad_moduel_object table to manage this new type of objects. ALO 2 6 Complete


12. Collaterals 12.4. Review order calculation for menu, fields and tabs ALO 2 7
12. Collaterals 12.5. Prevent modifications in seqNo for fields and menu entries ALO 1 5 N/A Complete
12. Collaterals 12.6. For webservices implementation it is needed to copy configuration files from to WebContent directory, these files currently are only in config core directory, modules should be able to have this directory too and copy its contents. ALO 0.5 5 N/A Complete
Change the way models are loaded to allow partial model loading. AMO 5 6
Remove column ordering and add a new formatter selection based on the object class instead of the model information in export process, to avoid model loading and greatly speed up the process. AMO 2 6
Verify the downloaded obx file is not corrupt using a MD5 hash or something similar. ALO 2 7
Currently the installation process reads the module information from the xml files included in the obx files and uses DBSM classes to persist it to database, it should be done using DAL classes instead. ALO 2 8


Dirty configuration script AMO
Change format of XML files AMO
Redefine as members of the application dictionary tables AD_ALERTRULE, AD_TREE, AD_TREENODEBP, AD_TREENODEPR AMO
Review the orphan entries in the Model Object table to be sure that there is no missing entry in the web.xml file ICI
Add validation: only references of type List Validation and Table Validation can be included in a module different to core ALO 6 Complete
Add validation: search keys in messages should start by the module db_prefix in a module different to core ALO 6 Complete
Review translation process: ensure that text interfaces entries are created assigned to modules properly (taking into account the packaging of the file) ALO 6 Complete
Create a new method to obtain all the modules ordered by dependencies ALO 6 Complete
Read dataset in order when importing reference data applying modules ALO 6 Complete
Add validation: ad_table.tablename, ad_table.name and ad_column.columnname must start with the module's db prefix. ALO 6 Complete
Apply modules when creating/updating db. ALO 6 Complete
Read dataset in order when importing reference data in initial client/org setup EAR 6
Manage module dependencies when importing reference data, not allowing to load data that does not fulfills dependencies. ALO 8
Declare and manage incompatibilities between modules including different versions of the same jar library ICI 8
Take into account workflows in synchronize terminology process. ALO 7
Remove AD_Module_Version* tables from Openbravo ERP, they only make sense in CR. Manage properly updates available in the scan for updates process. ALO 6 Complete


Remove AD_Module.IsActive template column which is not used. ALO 6 Complete
Prevent updates from MMC for modules that are in development. ALO


Retrieved from "http://wiki.openbravo.com/wiki/Projects:Modularity/ProjectPlan"

This page has been accessed 8,360 times. This page was last modified on 8 June 2012, at 05:28. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.