The contest "Professional Analyst" starts at InfoTeKS Academy
We are pleased to announce the start of accepting applications for the Professional Analyst competition in the framework of the Competition direction, in order to participate in which it is necessary to develop a universal cross-platform program code for creating reports (report generator) based on databases.
Anyone can participate in the competition, whose development corresponds to the parameters for usability and technical requirements stated by the organizers. A full list of job evaluation criteria can be found on the website academy.infotecs.ru / in the "Competition" section. At the competition, participants must submit a technical description of their own solutions and compiled code with an installer that allows you to automatically install the application.
The maximum prize is 350,000 rubles, the amount of money remuneration depends on the number of criteria to which the work submitted to the competition responds.
')
Applications and entries will be accepted until July 15, 2014, inclusive, by registering in the Personal Account and filling out the application on the website academy.infotecs.ru/ or by e-mail academy@infotecs.ru
Problem to be solved : development of universal cross-platform program code for creating reports (report generator) based on the database.
Materials transferred to the participant : dump database.
Materials submitted by the participant: compiled code with an installer that allows you to automatically install the application, a technical description of the implementation features, an application for participation in the selected task within the “Competition” format - is submitted through the Personal Account.
Requirements : the report generator should use no more than 300 MB of RAM, switching between report pages should take less than 3 seconds (the estimation of the switching speed will be carried out experimentally). The report generator should work in two modes: in the report design mode and in the report display mode. In the report display mode based on the template, the ability to save the report in PDF, RTF formats should be implemented; report types - grouping data by attribute, highlighting (highlight) values ​​by condition. A simple report without grouping, consisting of 5 columns and 10 thousand lines, should be formed in less than 5 seconds, and with grouping by one sign - in less than 10 seconds.
Conditions of implementation : x64 / x86, uses a DBMS that supports SQL-92 (preferably Postgres 9.1), third-party open source libraries are allowed. Database queries must support the SQL-92 standard. The report generator should be built on client-server technology. The server part, which is responsible for connecting to the database and generating reports, must be built in Java and must support operation under the control of Apache Tomcat. The client part must have a web interface that uses JavaScript, and function in the following browsers: Internet Explorer 9+, FireFox 24+, Google Chrome 28+. The database dump received from the Organizers should be used as the database (server side).
Functional requirements : The report module must have a web interface and use the Connection String to access the database, using view sets to obtain information about the data sets available for work and their composition.
Sets view :
TABLE_VIEW
FIELD_VIEW
RELATIONS_VIEW
Report Design Mode
In report design mode, the report generator should allow you to create WYSIWYG templates that will be used to build the report. The user should be able to create a template based on the data from the dataset provided by the database. Created templates must be saved locally in XML format. The report should be able to use caps, basements, data panels, tags, images.
Report display mode
In this mode, the ability to display the report based on previously created templates and save the generated report in various formats should be implemented (PDF, RTF is the main requirement; XLSX, XML is optional; see the sections: “Requirements” and “Additional Requirements”) . The ability to display the WYSIWYG report in a separate window for printing should also be implemented.
Evaluation criteria : participants submit a technical description and a compiled code with an installer for the competition, which allows to automatically install the application. Testing is conducted on the side of the Organizers (bench parameters: Windows Server 2008 R2 64bit, Intel Core i7 3Ghz, 8Gb RAM), the results are recorded and published in the overall standings. Evaluation of the implementation parameters of each of the participants is publicly available.
As a result, the weighted average value of all evaluation criteria is taken (see sections: “Requirements” , “Implementation conditions” ), for example, the number of report types supported by the application is calculated, the minimum time to switch between reports (report pages) is estimated. Similarly, participants are awarded bonus points for fulfilling the greatest number of additional requirements, including usability.
Additional Requirements (General)
Additional requirements add points to participants if the basic requirements are met and include the following:
Additional requirements (usability)
Additional requirements related to usability requirements also add points to participants, provided that the basic requirements are met. The evaluation of the usability program is carried out on the basis of the following criteria (considered as a point grade by equivalent positions):
1. It is recommended to use the style "Metro Style".
2. It should always be possible to determine the state of the system.
3. It should be easy to understand what information is available at a given place.
4. It should be obvious which elements are “operable”.
5. It should be clear what will happen when interacting with the element.
6. The information provided must meet expectations.
7. It should be clear where you can go from the current location.
8. All functions must be clearly and clearly marked.
9. “Extra” technologies should not be used.
10. The purpose of the controls, their location and names should be consistent throughout the interface.
11. Links and menus should be used and displayed in accordance with accepted web standards.
12. The site should be correctly displayed in all major browsers.
13. The names of the links should correspond to the titles of the pages to which they lead.
14. The behavior of the program must meet expectations.
15. The program should use the minimum help, tips, instructions.
16. Form fields should create an idea of ​​the entered information or contain short hints.
17. It should not be necessary to remember all the actions, objects and options that are visible on the screen in order to use them.
18. In appearance, elements from past experience should be easy to establish how to interact with them.
19. All possible actions should be clearly marked.
20. Tags and links should have clear and understandable descriptions.
21. Key program features should be available in all screens.
22. Visual solutions of the site should be concise and readable.
23. Paragraphs should be short.
24. On the page there should be a sufficient amount of free space - “air”.
25. The site should not contain unnecessary animation and load-bearing images.
26. Graphic design must fit context.
27. Pages should be organized in a clearly readable structure and contain the necessary details.
28. The interface should allow the user to recover from an error.
29. Error messages should be displayed in a language that the user understands.
30. The error message should describe the problem as precisely as possible and suggest a solution.
31. Forms and input fields should restore values ​​after a failure or erroneous acceptance.
32. The interface should contain a help system.
33. Assistance should be focused on user tasks and contain a list of specific steps.
34. Help should not be great.
35. Hints in the interface should be informative.
Anyone can participate in the competition, whose development corresponds to the parameters for usability and technical requirements stated by the organizers. A full list of job evaluation criteria can be found on the website academy.infotecs.ru / in the "Competition" section. At the competition, participants must submit a technical description of their own solutions and compiled code with an installer that allows you to automatically install the application.
The maximum prize is 350,000 rubles, the amount of money remuneration depends on the number of criteria to which the work submitted to the competition responds.
')
Applications and entries will be accepted until July 15, 2014, inclusive, by registering in the Personal Account and filling out the application on the website academy.infotecs.ru/ or by e-mail academy@infotecs.ru
Problem to be solved : development of universal cross-platform program code for creating reports (report generator) based on the database.
Materials transferred to the participant : dump database.
Materials submitted by the participant: compiled code with an installer that allows you to automatically install the application, a technical description of the implementation features, an application for participation in the selected task within the “Competition” format - is submitted through the Personal Account.
Requirements : the report generator should use no more than 300 MB of RAM, switching between report pages should take less than 3 seconds (the estimation of the switching speed will be carried out experimentally). The report generator should work in two modes: in the report design mode and in the report display mode. In the report display mode based on the template, the ability to save the report in PDF, RTF formats should be implemented; report types - grouping data by attribute, highlighting (highlight) values ​​by condition. A simple report without grouping, consisting of 5 columns and 10 thousand lines, should be formed in less than 5 seconds, and with grouping by one sign - in less than 10 seconds.
Conditions of implementation : x64 / x86, uses a DBMS that supports SQL-92 (preferably Postgres 9.1), third-party open source libraries are allowed. Database queries must support the SQL-92 standard. The report generator should be built on client-server technology. The server part, which is responsible for connecting to the database and generating reports, must be built in Java and must support operation under the control of Apache Tomcat. The client part must have a web interface that uses JavaScript, and function in the following browsers: Internet Explorer 9+, FireFox 24+, Google Chrome 28+. The database dump received from the Organizers should be used as the database (server side).
Functional requirements : The report module must have a web interface and use the Connection String to access the database, using view sets to obtain information about the data sets available for work and their composition.
Sets view :
TABLE_VIEW
| Field name | Field type | Note |
| ID | integer | Table ID |
| TABLE_NAME | Varchar (255) | Table name |
FIELD_VIEW
| Field name | Field type | Note |
| ID | integer | Field id |
| FIELD_NAME | Varchar (255) | Field name |
| FIELD_TYPE | Varchar (255) | Field type |
| IS_NULL | boolean | Sign of commitment |
RELATIONS_VIEW
| Field name | Field type | Note |
| ID | integer | Connection id |
| PARENT_TABLE_ID | integer | Parent table |
| CHILD_TABLE_ID | integer | Child table |
| PARENT_FIELD_ID | integer | Parent field |
| CHILD_FIELD_ID | integer | Child field |
Report Design Mode
In report design mode, the report generator should allow you to create WYSIWYG templates that will be used to build the report. The user should be able to create a template based on the data from the dataset provided by the database. Created templates must be saved locally in XML format. The report should be able to use caps, basements, data panels, tags, images.
Report display mode
In this mode, the ability to display the report based on previously created templates and save the generated report in various formats should be implemented (PDF, RTF is the main requirement; XLSX, XML is optional; see the sections: “Requirements” and “Additional Requirements”) . The ability to display the WYSIWYG report in a separate window for printing should also be implemented.
Evaluation criteria : participants submit a technical description and a compiled code with an installer for the competition, which allows to automatically install the application. Testing is conducted on the side of the Organizers (bench parameters: Windows Server 2008 R2 64bit, Intel Core i7 3Ghz, 8Gb RAM), the results are recorded and published in the overall standings. Evaluation of the implementation parameters of each of the participants is publicly available.
As a result, the weighted average value of all evaluation criteria is taken (see sections: “Requirements” , “Implementation conditions” ), for example, the number of report types supported by the application is calculated, the minimum time to switch between reports (report pages) is estimated. Similarly, participants are awarded bonus points for fulfilling the greatest number of additional requirements, including usability.
Additional Requirements (General)
Additional requirements add points to participants if the basic requirements are met and include the following:
- Types of reports:
- Grouping by range;
- Cross-table;
- Multicolumn report;
- Report in the form of cards;
- Master-detail-report;
- Saving report in formats: XLSX, XML.
- Support for math functions, functions for working with lines and dates, page count.
- Sort by tabular parameters.
- Search by report.
Additional requirements (usability)
Additional requirements related to usability requirements also add points to participants, provided that the basic requirements are met. The evaluation of the usability program is carried out on the basis of the following criteria (considered as a point grade by equivalent positions):
1. It is recommended to use the style "Metro Style".
2. It should always be possible to determine the state of the system.
3. It should be easy to understand what information is available at a given place.
4. It should be obvious which elements are “operable”.
5. It should be clear what will happen when interacting with the element.
6. The information provided must meet expectations.
7. It should be clear where you can go from the current location.
8. All functions must be clearly and clearly marked.
9. “Extra” technologies should not be used.
10. The purpose of the controls, their location and names should be consistent throughout the interface.
11. Links and menus should be used and displayed in accordance with accepted web standards.
12. The site should be correctly displayed in all major browsers.
13. The names of the links should correspond to the titles of the pages to which they lead.
14. The behavior of the program must meet expectations.
15. The program should use the minimum help, tips, instructions.
16. Form fields should create an idea of ​​the entered information or contain short hints.
17. It should not be necessary to remember all the actions, objects and options that are visible on the screen in order to use them.
18. In appearance, elements from past experience should be easy to establish how to interact with them.
19. All possible actions should be clearly marked.
20. Tags and links should have clear and understandable descriptions.
21. Key program features should be available in all screens.
22. Visual solutions of the site should be concise and readable.
23. Paragraphs should be short.
24. On the page there should be a sufficient amount of free space - “air”.
25. The site should not contain unnecessary animation and load-bearing images.
26. Graphic design must fit context.
27. Pages should be organized in a clearly readable structure and contain the necessary details.
28. The interface should allow the user to recover from an error.
29. Error messages should be displayed in a language that the user understands.
30. The error message should describe the problem as precisely as possible and suggest a solution.
31. Forms and input fields should restore values ​​after a failure or erroneous acceptance.
32. The interface should contain a help system.
33. Assistance should be focused on user tasks and contain a list of specific steps.
34. Help should not be great.
35. Hints in the interface should be informative.
Source: https://habr.com/ru/post/214885/
All Articles