29/07/2018 at 21:47 #11252
We are engaged in a project to enhance software development performance management using COSMIC as product unit measurement. There is an enhancement demand created in order to reestructure the menu navigation and the navigation flow between transactions.
I have analysed the manual and figured out this demand is beyond the applicability of the COSMIC method due to the references in the end of this message.
However, I’m not yet sure about this conclusion because of other rulings on 4.4.1, which includes: … ‘Presentation’ can mean, for example the font, background colour, field length, field heading, number of decimal places.
Thanks in advance.
Control commands and application-general data of business applications do not involve data movements, as no data about objects of interest are moved. Therefore, changes to control commands and application-general data should not be measured. As an example, when the screen colour for all screens is changed, this change should not be measured. (See section 3.5.10 for an explanation of control commands and application-general data.)
Pages 70 & 71:
DEFINITION – Control command: A command that enables human functional users to control their use of the software but which does not involve any movement of data about an object of interest of the FUR of the software being measured.
NOTE: A control command is not a data movement because the command does not move data about an object of interest.
RULE – Control commands in applications with a human interface: In an application with a human interface ’control commands’ shall be ignored as they do not involve any movement of data about an object of interest.
EXAMPLES OF CONTROL COMMANDS
· Menu commands that enable a user to navigate to one or more specific functional processes but which do not themselves initiate any one functional process,
This question was first posted on LInkedin.
29/07/2018 at 21:52 #11254
I think you are correct in concluding that a required change to a ‘pure’ menu command should not be counted as a change to a data movement according to the MM v4.0.2 (where a ‘pure’ menu command is one that only assists user navigation to different parts of the software or that causes only a data entry screen for a functional process to appear without any attributes of the triggering Entry of the process having been entered.) Alternatively, if any the menu commands enable one or more attributes of the triggering Entry of a functional process to be entered, then required changes to these commands may obviously be interpreted as changes to the affected triggering Entries, as per the normal rules.
However, given that you are engaged in a project where you are required to use COSMIC as the size measurement method, you should be entitled to invent a ‘local extension’ to the method for the case of measuring required changes to ‘pure’ menu commands which is not covered by the standard method.
One way to deal with this would be to think of the menu navigation system as a separate piece of software of defined scope. (Maybe it would help to think of the menu navigation system as in a different layer from the layer in which the application resides?) Assuming the menus have a tree-like structure, you must then identify the object of interest types of this structure. This ‘structure’ is effectively a ‘data structure’ that is persistently ‘stored’ (either actually hard-coded or actually stored as a maintainable structure) by the menu navigation software. You must then define the functional processes that must be developed to make the required changes to this structure.
At this point I must stop trying to help because I have no knowledge of how your menu system actually works and the degree to which it is independent of the functional processes to which it provides access. Changes might be needed to the application arising from changes to be made to the menu navigation software.
I hope this helps.
30/07/2018 at 21:56 #11256
Thank you for you formidable attention.
I’ve done as you instructed.
Since we are the ones defining COSMIC usage, we can and will add the extension to the rule you mentioned.
We favored COSMIC to IFPUG FP+SNAP solution due to the simplicity of a single unit to measure functional and non-functional requirements.
However, it seems to me there is space to enhance the standard so we don’t need this extension.
Once more, thanks! And if you ever come to Brazil again, please let me know.
Carlos Eduardo Meira-Vazquez, CFPS
01/08/2018 at 22:00 #11258
If a command button leaves no traces on data stored or moved in a system, it’s clearly not counted. Examples include changing screen colors without remembering the changed color for the future.
However, as soon as the command button changes persistent data, for instance in a user settings functional process (FP), it clearly moves data from and to this FP and is being counted. With user settings, you have a full CRUD. This is similar to IFPUG: as soon as you have persistent data in some ILF, you count the Entries, the eXits (or EI, EO, EQ), and obviously the Reads and Writes necessary to present data to the user on some suitable device. This is common for adaptive design on Web Servers, well explained in the COSMIC manual and stuff for a guideline.
You must be logged in to reply to this topic.