Tagged: Identify data groups in reports
17/10/2018 at 00:34 #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:
plus the character “.”
plus the last name
plus the phase “@empresa.com”
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 email@example.com 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!!
18/10/2018 at 20:41 #11349
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.
18/10/2018 at 22:50 #11350
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
24/10/2018 at 16:26 #11357
Thank you very much. Your answere has been very helpul
You must be logged in to reply to this topic.