COSMIC Sizing Forums COSMIC Size measurement Identify data groups in reports

Viewing 3 reply threads
  • Author
    • #11347

      I have 4 specific questions, that has come up during my measurements:

      1) There are two applications A and B. The FUR to measure are in application A and B is a functional user of A
      In application B there are information about two objects of interest, one of them “Employee” with the attributes IdEmployees, Name, Address, PhoneNumber, etc., and other object of interest name “Salary” with the attributes “amount”, “Date to started with this salary”, etc.

      If I am measuring Application A and it must receive the following information from Application B: IdEmployees, Name, “salary amount”

      On the one hand, I could think that there are 2 entries, according with Measurement Manual Version 4.0.2, pp. 52, which say “set of data attributes that have the same frequency of occurrence but different identifying key attributes(s) describe different objects of interest

      On the other hand, I could think that there is only 1 entry
      Must I must count 1 o 2 entries?, which is the reference?

      2) Other example, If I am measuring application B and it has to read the information of the “Employee” with the attributes IdEmployees, Name, Address, PhoneNumber and the information of other object of interest “salary” with the attributes “amount”, “Date to started with this salary”, and application B needs to send the following information to another functional user:
      “IdEmployees, Name, Address, PhoneNumber, “salary amount”, “Date to started with this salary”
      Must I count 2 reads and only 1 exit?, which is the reference?

      3) If I am measuring application B and the application needs to read information of “Employee” with the attributes IdEmployees, Name, Last Name, Birthdate, number of City of Birth
      And information from “Salary” with the attributes “amount”, “Date to started with this salary”, etc.

      It is necessary to show the following report, where CURP is calculated with:
      the 2 first characters of the name
      plus the first character of the last name
      plus the first character of the mother’s last name
      plus the birthdate
      plus the Number of the City of birth

      The email is obtained by concatenating:
      the name
      plus the character “.”
      plus the last name
      plus the phase “”

      The sum of salary payed in the last 3 years is calculated using the “mount of salary” and “Date to started with this salary”

      Name Last Name Mother’s last name CURP Email Sum of salary payed in the last 3 years
      Sandra Lopez Sanchez SALS1203OCRRR03 123,456,78
      Must I count only 1 exit?

      4) In the COSMIC-Method-v4.0.2-Measurement-Manual pp. 52, the rule C is not so clear, could you give an examen?

      Thanks you very much!!

    • #11349
      Arlan Lesterhuis

      Dear Mary,

      Below my answers with explanations and reference where needed,

      1) The IdEmployee, Name, and “salary amount” are required, where there is only one salary amount (namely the salary amount at this moment), all attributes describe one OOI that could be called ‘Employee data’, because for the given ID there is only one name and one salary amount. Identify one Entry, even when this data is required for many employees (these would be many occurrences of the same data group)

      Note: it would be different when the request is to display the IdEmployee, Name, but with a number of the “salary amounts”, in that case there is difference in frequency, hence two Entries.

      2) That is correct: in app B data of two OOIs must be read (Employee and Salary), i.e. two Reads, however the data group IdEmployee, Name, Address, PhoneNumber, “salary amount”, “Date to started with this salary” describes the one OOI ‘Employee data’, hence one Exit.

      3) One Exit is correct, the data ‘Sandra Lopez…123.456.78’ describe one OOI (also if the data group is produced for many employees)

      4) When just reading Rule c) of 3.3.2 it is rather abstract, however Note 3 refers to some examples, see e.g. Ex. 2:
      Normally, all data describing one OOI that is made persistent by a functional process is identified as one data group moved by one Write. Example 2 shows that if FUR specify that different data groups must be moved to persistent storage by a functional process, although they describe the same OOI, then two Write shall be identified.

      I hope that this is clear.

      Best regards,

      Arlan Lesterhuis

    • #11350
      Charles Symons

      Dear Mary, when I checked there was no reply to your questions, so after dinner I came back and wrote a reply, which I have copied below. No surprise – I agree with Arlan Lesterhuis’s solutions. Here is my reply to your same questions:
      Hi Mary, thank you for these good questions. Let’s summarise your situation.
      You have two Applications A and B that communicate with each other. Each App must be measured separately, so has its own ‘measurement scope’.
      App A knows only the interface to app B. App A knows nothing about the functionality inside App B, and vice versa. It follows that each App can have its own ‘internal’ objects of interest. (I don’t think that my conclusion is stated anywhere explicitly in the Measurement Manual, but the situation described above is given as in section 4.5.1, case 1b, in the ‘Guideline for sizing Business Application Software’, v1.3, and in earlier versions.
      Question 1: App A sends a request for data about an employee to App B via one Exit and receives the result via one Entry. (Each DM moves one DG describing the OOI ‘employee’.) App A does not know that App B had to consult data describing two OOI’s internally in order to generate the Exit to App A. App A is not interested in what happens inside App B, and vice versa.
      Question 2: Yes, count two Reads (obviously) and only one Exit. All the attributes of the DG moved by the Exit describe one OOI, ‘employee’. (All attributes that you list occur once for each occurrence of ‘employee’.) The attributes in the Exit could be named ‘Current Salary’ and ‘Starting Date of the Current Salary. In contrast, in the persistent data of the ‘Salary History’ record in App B, the attributes could be named ‘Salary at the given Starting Date and ‘Starting Date’. The attributes in the persistent data record are not the same as the attributes in the ‘Salary History’ record. They have different meanings.
      Question 3: Yes, there is only one Exit for the report that you describe. The employee ID (‘CURP’?) is a composite of other data but it is issued as one attribute of one OOI.
      Note that for App B to obtain the employee details from App A that App B needs to compose the CURP, App B will have to obtain these details via an X/E pair to/from App A.
      Question 4: Re rule c) on page 52 of the MM v4.0.2. Rule c) refers to Note 3, which in turn refers to several examples in section 3.5.7, and to section 3.5.11 for some exception examples. I hope these are all clear.
      I hope this is all OK.
      Regards Charles Symons

    • #11357
      Maricela Martínez

      Thank you very much. Your answere has been very helpul

Viewing 3 reply threads
  • You must be logged in to reply to this topic.