c.-SAMM for Lotus Notes - DASMAdasma.org/contray/media/pdf/c.-SAMM-FSM_for_Notes... · 0.8 21.03.2012 Michael Otto Review by Manfred Seufert, Mediaan ... Cedros developed the toolset

Cedros Gesellschaft für Datenverarbeitung mbH Siegburger Straße 35 D-53757 Sankt Augustin

Tel: +49 2241 8834 0 Fax: +49 2241 8834 11 e-Mail: [email protected]

Seite:

Stand:

1/23

24.10.2012

c.-SAMM for Lotus Notes

Adaption of FiSMA 1.1 for Lotus Notes/Domino

Functional Size Measurement of Lotus Notes applications

This guideline describes the appliance of the specifications of the FiSMA 1.1 Functional Size

Measurement Method for IBM Lotus Notes/Domino applications. Besides defining the mapping of

Notes design-elements to FiSMA BFC-types the document specifies a standard on how to appraise

design-elements and how to proceed in case of ambiguity.

Information Basis

Preparation

Counting

Results

Forms / Dialogs

Views

Code

Security Routines

Interfaces

Use Cases

c.-SAMM for Lotus Notes – FSM Guideline Adaption of FiSMA 1.1 for Lotus Notes/Domino

Cedros Gesellschaft für Datenverarbeitung mbH | Siegburger Straße 35 | D-53757 Sankt Augustin

Tel: +49 2241 8834 0 | Fax: +49 2241 8834 11 | e-Mail: [email protected] | www.cedros.com

Page:

Last edited:

2/23

24.10.2012

Document

File c.-SAMM - FSM for Notes Databases 1.0 - Englisch.docx

Author Markus Michels; [email protected]

Version 0.9

Status In progress / Submitted for approval

Document History

Version Datum Bearbeiter Änderung

0.7 08.02.2012 Michael Otto Updated, English version

0.8 21.03.2012 Michael Otto Review by Manfred Seufert, Mediaan

0.9 28.08.2012 Markus Michels Review by Pekka Forselius, 4SUM Partners

1.0 24.10.2012 Markus Michels Final version




Page:

Last edited:

3/23

24.10.2012

Table of contents

1 ABSTRACT 5

2 INTRODUCTION 6

2.1 INFORMATION BASIS 6

2.2 COURSE OF ACTION 7

2.2.1 PREPARATION 7

2.2.2 COUNTING 7

2.2.3 RESULTS 8

2.3 NOTES DESIGN ELEMENTS 9

2.4 TECHNICAL COMPLEXITY 10

2.5 DIALOGS 10

2.5.1 STANDARD-DIALOGS / SYSTEM-DIALOGS 10

2.5.2 APPLICATION-DIALOGS 10

2.5.3 EXCLUSIONS (ERROR MESSAGES) 11

2.6 PLATFORM-FUNCTIONALITY 11

2.7 MULTILINGUALISM 11

2.8 ENTITIES 12

2.9 EXCLUSIONS 12

3 MAPPING OF DESIGN-ELEMENTS TO BFC-TYPES 13

4 EXPLANATION REPORT 16

4.1 „COUNT FUNCTIONALITY“ 16

4.1.1 EXAMPLE “VISITOR-DATABASE” 16

4.1.2 EXAMPLE „EXAMPLECOMPANY CRM“ 16

4.2 USER INTERFACE 16

4.2.1 WEB-INTERFACES DETECTION 16

4.2.2 NAVIGATION 17

4.2.3 VIEWS / EMBEDDED VIEWS 17

4.2.4 PICKLISTS 18

4.2.5 FORMS / EMBEDDED FORMS 18

4.2.6 SUB-FORMS 18

4.2.7 PAGES, OUTLINES, FRAMESETS 19

4.2.8 ACTIONS 19

4.2.9 DATABASE-PROPERTIES 19

4.2.10 TOOLTIPS 19

4.3 SECURITY ROUTINES 20

4.3.1 USAGE OF ROLES 20

4.3.2 READER-/AUTHOR-FIELDS 20

4.3.3 VIEW-/FORM-PROPERTIES 21

4.4 INTERFACES 21

4.4.1 MAIL-IN DB 21

4.4.2 OUTBOUND MAIL 22

4.4.3 DATABASES 22




Page:

Last edited:

4/23

24.10.2012

4.5 CODE 22

5 CHECKLISTS 23

5.1 COMPLETE COUNTING CHECKLIST 23

About the Author

Cedros has been active in the field of Lotus Notes application development for 20 years. In

addition Cedros is an active member in the DASMA1 and the biggest contributor of FiSMA

nothernSCOPE™2 in Germany. For further information please refer to:

http://www.cedros.com/en/enterprise-software-solutions/anwendungsentwicklung/software-metriken-und-analyse/

This document was developed with support from Mediaan3. The company has been active in the

business field of Software Metrics for more than 25 years. The appliance of Function Points

(IFPUG4, NESMA

5 and FISMA

2) including Benchmark Analysis is Mediaans´ passion as well as the

consulting and training of Scope Managers as a partner of the ECQA6.

Special thanks to Manfred Seufert, Mediaan and Pekka Forselius, 4SUM Partners for review

support. They are both members of ECQA job role committee for Certified SCOPE Manager and

represent DASMA and FiSMA organisations. Pekka is the original editor oft he FiSMA 1.1 method

and ISO standard.

1 Deutschsprachige Anwendergruppe für Software-Metrik und Aufwandsschätzung e.V. – www.dasma.org

2 FiSMA Scope Management -- http://www.fisma.fi/in-english/scope-management/

3 MediaanABS Deutschland GmbH - http://www.mediaanabs.de/

4 International Function Point User Group (http://www.ifpug.org/)

5 Netherlands Software Metrics Association (http://www.nesma.nl/section/home/)

6 European Certification & Qualification Association – http://www.ecqa.org




Page:

Last edited:

5/23

24.10.2012

1 Abstract

Lotus Notes / Domino® is an application runtime environment developed by IBM. Furthermore its

integrated Domino Designer is used as a rapid application development (RAD) environment.

Functional Size Measurement Method (FSM) enables to measure the amount of functionality of a

software project based on its specification. The functional size of an application is measured in the

abstract unit FiSMA Function Points (Ffp) and is independent of the project’s circumstances like

the programming language or frameworks employed, the programmers’ experience etc. The

functional sizes may be used to compare projects or to price them. Functional size together with

information about the project’s circumstances, and a typical delivery rate (hours/Ffp) from

empirical data of similar projects, can be used for estimating an applicable implementation

time/schedule and effort.

In 2008 the Finnish Software Measurement Association (FiSMA)7 developed an international

standard for this methodology (ISO/IEC 29881:2008). However the methodology is not applicable

or applicable with reservations only for Lotus Notes applications since they provide several

challenges for the metrics specialists for to the following reasons:

• Due to the fact that Lotus Notes provides an RAD-environment usually the applications are not

based on a functional specification but often are prototyped in continuous consultation with

the customer. Most likely a functional specification reflecting the current state of an

application is not available.

• Even if a functional specification is at hand it may differ significantly from the particular

application. This is caused by the fact that oftentimes functionality is included that has not

been specified explicitly but is provided by the Notes framework itself. Counting this

functionality would contradict the paradigm that the measured result is independent of a

project’s circumstances. Instead this is and should be reflected by the Lotus Notes-specific

delivery rate.

• Data management is not based on a relational model as customary but on a document-based

database. These two paradigms differ in certain aspects considerably that are of importance

for a Functional Size Measurement. Neither FiSMA nor any other Functional Size Measurement

Method standard does not cover this topic.

Thus most of the time the requirements to conduct an analysis as specified in the standard are not

given. Hence there is need for a set of rules that allow processing Lotus Notes applications as well.

This document provides a methodology developed by Cedros8 that identifies the Lotus Notes-

specific characteristics that might adulterate, aggravate or inhibit a functional size measurement.

For each characteristic a course of actions accordant to FiSMA is described.

7 Finnish Software Measurement Association - http://www.fisma.fi/in-english/

8 Cedros Gesellschaft für Datenverarbeitung mbH – http://www.cedros.com/en/enterprise-software-

solutions/anwendungsentwicklung/software-metriken-und-analyse/




Page:

Last edited:

6/23

24.10.2012

2 Introduction

The aim of this document is to define a best practice guideline for applying Functional Size

Measurement based on FiSMA 1.1 to existing Lotus Notes-application. By this way functional size

estimations are standardized and different function point analysts will come to the same result.

2.1 Information basis The input of the measurement mostly is a Lotus Notes-database or seldom a specification that

describes the Lotus Notes-elements in detail.

Cedros developed the toolset c.-AppScale that analyzes the design of Lotus Notes-applications and

measures their implementation efforts. For the set of applications the implementation efforts are

computed based on international standards in the field of software metrics. Additionally self-

developed algorithms will reveal criterions like “Dead Code” and “Duplicate Code” but these will

be of no importance for the matter of this document. Furthermore the interfaces and Lotus-Notes

features, being functionality that is added by the Lotus Notes-framework with low effort or none

at all, are detected and listed. Note that this analysis is based on the technical states of the input

applications as opposed to the FiSMA-methodology that processes functional specifications.

The following information will be used

• The application in the Lotus Notes client respectively in a web browser

• The specification (functional specification or equivalent document, if present)

• The database’s ACL

• Partially the database’s design

The manual counting focusses on determining the Function Points sufficiently within a fixed

amount of time. Therefore the counting will be based on the User Interface by default. This means

that only apparent respectively specified functionality will be counted. This is in line with the basic

principles of FiSMA 1.1 method: „If the user doesn’t recognize and understand functionality, it

cannot be based on FUR (Functional User Requirements), but the technical implementation needs

only.

For given applications a detailed definition may be carried out using the Domino Designer (e.g.

identification of interfaces) and as well as code analysis. Both does increase the timely effort and

is not in accordance with the principles of functional size measurement. Hence these tasks will

only be performed if necessary. The reason that necessitates the particular measure will be

specified. Then the following continuative information will possibly be required:

• The database’s (.nsf)/template’s (.ntf) design opened in the Domino Designer

• Database-specific entries in the Domino Directory

• Source-code (agents, class libraries etc.)




Page:

Last edited:

7/23

24.10.2012

2.2 Course of action

2.2.1 Preparation

Some preparations have to be made before the counting of an application can be started.

• The application has to be supplied on a Domino-server (adhere required server-version /

configuration where necessary)

• The application should be copied and used in isolated context. This helps identifying interfaces.

It is recommended to proceed the same way if uncertainties regarding the impact of actions on

the live system exist.

• A user-ID with all authorizations and roles and Designer-rights is established. Make sure that

the selected roles enable visibility of the complete functionality (e.g. Notes supports hiding

section in a form depending on the user role).

• The database-configuration is carried out (properties, key-word lists, etc.)

• Test the database regarding XPages and if it employs Java. This is not done currently.

• Identify roles/ACL and record in an overview.

• Test the Domino Directory for Mail-In entries and provide an overview where applicable.

If the counting is based on a specification then it has to be tested for consistency. If details are

missing and can or should not be questioned, then assumptions are to be made. These have to be

stated in the counting’s documentation unconditionally. If both the application as well as the

specification is available, then the specification has to be read in preparation. Nevertheless the

counting is based on the application to avoid gaps where the specification does not match the

application’s current state of development. On the other hand, logical correlations and general

functionality can be taken from the specification.

A lot of Lotus Notes-applications are implemented in consultation with the customer or

augmented with “nice features” because the required effort is marginal. In the majority of cases

the specification is not adapted adequately. If for an example a specification is present and one

view is implemented but not described in the specification one has to ask themselves if it really

belongs to the functional requirements. In case of doubt these are not counted but documented

adequately.

2.2.2 Counting

Regarding the counting the following rules have to be followed:

• Each view, form, menu etc. is handled in its maximal characteristic. This means that any field

that any user might access or that might be shown depending on the state of a workflow has

to be revealed and counted. To do so the application has to be verified for each role

respectively different states of the document have to be created.

• If the data model is not specified explicitly the entities are recorded as soon as they are

recognized during the counting.

• If interfaces and reports are not specified these are recorded as soon as they are recognized

during the counting.

• System-date, ACL, role, username, replica-ID etc. will be assigned to the system-entity and

counted with one read.




Page:

Last edited:

8/23

24.10.2012

• The Notes-tile is counted as an icon with n=1, r=1 except if the unread-count has a specific

functional meaning. In this case a data inquiry (n=2, r=1 for the count and the link) is charged.

Each tile shall be counted only once per application, even if it occurs several times.

• Each icon and menu is counted as one read on the system-entity.

• Each dialog and form is counted as one read on the system-entity (no multiple counting). Each

data element is processed with a base value of 2 (window, title)

• According to FiSMA 1.1’s common rule, help texts will not be counted as independent

functions (BFC’s). They are part of implementation of the usability (quality) requirement. If

there is a long help text library with many links, it may be counted as an inquiry screen, where

the number of links is the number of data elements.

• If an action bar contains more than 5 buttons, then these are to be listed by name in the count

documentation. Since some of them are visible only given a particular context this course of

action eases the possibility to validate which ones have already been counted.

• The document-history is assessed as a common sub-form and counted once only, except

if/when it is apparently specified or implemented differently.

• In case of an error the function point analyst has to try to bypass it to reveal the hidden

functionality or to detect it in a different way. This can be achieved by reading the functional

concept or by consulting the developer. If the function point analyst is not able to determine

and measure the functionality even so, he can make assumptions but has to protocol these

accordingly.

• Assumptions should be verified as far as possible with an application expert.

2.2.3 Results The current version of the Cedros template c.-Ffp Calculator.xlsm is used to document the

counting. As a rule two subprojects (in a northernSCOPE sense) will be created

1. Standard design elements

These cover all design elements that are not categorized as simple

2. Simple design elements of this group (primarily views with different sort or categorization) are

captured here and contribute to the effort’s calculation with a lower delivery rate.

The key parameters relevant for the counting will be recorded per entry

• Code of the BFC-Type (see Tab [BFC Reference])

• The values for n, r, w, o

• The calculation formula in the comment column

The following notation is employed:

f=<Number of fields, including the title and background of the window>; d=<Number of default-

values>; s=<Number of sections/categories>; b=<Number of buttons>; l=<Number of links>;

c=<Number of columns>; x=<Number of sorts>; t=<Number of totals (=summations)>;h=<hidden

elements> for error messages and warning messages




Page:

Last edited:

9/23

24.10.2012

Example:

7f+3b+1l Form containing 7 fields, 3 buttons, and 1 link; n=11

4c+2s View containing 4 columns and 2 categories; n=6

Roles, entities of the data model and, if present, reports as well as interfaces are captured and

processed on individual tabs

The result covers each sub-project as well as the summarized Function Points measuring each sub-

projects’ functional size independent of the programming language and frameworks for each sub-

project, the programmers’ experience and the like. Based on these results and by means of a

Delivery Rate the expected expenditure of time and effort required to implement a (sub-)project is

computed. The Delivery Rates for all sub-projects are derived from benchmark data.

Important: Assumptions made due to missing information or functional specification have to be

documented. If the counting is based on a written specification then the chapter and the page

number have to be specified.

2.3 Notes design elements Each Notes database contains the following design elements besides the data documents

• Database: database-tile shown in the workspace

• Views: views, forms, pages

• Menus: action bars, create-entries, context-menus, smartIcons

• Navigator: outline

• Source-code: @Formula, LotusScript, Java in the UI, classes or agents

• Web-Services

• Using this Database, About this Database

• Profile-documents

An application’s ACL defines

• Authorizations

• Roles

Each database can be configured to be a Mail-In-database, which in fact represents an interface of

the kind Interface FROM Other Application. Additionally interfaces within Lotus Domino or to other

systems may be implemented using Domino-connectors (Lotus connectors, DECS, LEI, SAP JCO,

etc.).

The Functional Size of XPages aspects has to be counted in a separate sub-project but differs from

standard Lotus Notes functionality. Therefore the concrete counting is beyond the scope of this

guideline and will not be addressed.




Page:

Last edited:

10/23

24.10.2012

2.4 Technical complexity The technical complexity of a Notes-database is determined through the amount of source-code,

the distribution of backend- and frontend-functionality, the usage of roles etc. When determining

the expenditure of time that the development of a given database requires this complexity

certainly may not be neglected. For instance Notes-databases that use interfaces, replications etc.

are more time-consuming to implement than a “simple workflow-application” even if their

functional sizes (FPs) are equal.

Currently this factor is not considered. The aim is to enhance the methodology to collect

benchmark data that enables an adjustment of the expenditures based on the technical

complexity.

2.5 Dialogs

2.5.1 Standard-dialogs / system-dialogs Each technical platform provides an asset of standard-dialogs. For Lotus Notes these are e.g.

search-dialogs, name-choice, font-choice, file open/save as etc.

Dialogs that represent system functionality (operating system, Lotus Notes) and that are not

requested explicitly by the user are counted as Generation Dialogs (q5) where n and r are set to 1.

These values represent the call of the related functionality. Examples are “print”, “choose

application”, “file selection”, “create mail” …

Reference values for requested dialogs are:

• „Attach file“ -> Generation Dialog (q5) n=5, r=1 (3f+2b)

• „Select name(s)“ -> Generation Dialog (q5) n=5, r=1 (3f+2b)

If the functionality of external systems is called, then additional Messages OUT (t1) should be

recorded (e.g. Lotus Sametime-functionality is used explicitly).

If one aspires to compute a normalized FP-value representing the effort to migrate the

functionality to different platforms, additional Function Points have to be counted. During the

course of advancement of this guideline, the determination of Function Points for generic dialogs,

that fulfill the required functionality, but do use none given by the platforms, will be addressed.

If the target platform provides a standard-dialog that supplies the required functionality it will be

counted in a sub-project of its own. This project has a project reuse multiplier (reuse factor) of 0

that will be multiplied with the counted Function Points.

2.5.2 Application-dialogs Application-specific dialogs will be counted according to their usage. The choices are either a

Generation Dialog (q6) or 1-Function Input (i1). The latter one will be chosen if the dialog is used

to manipulate an entity.




Page:

Last edited:

11/23

24.10.2012

During the counting each dialog will be counted as soon as he is distinctive with regards to

contents from all previous ones. Even in case of great similarity the dialog will be processed

separately. An exception is if the sole deviation is the dialog’s title. In this case it will not be

counted (if the dialog itself is not different!).

2.5.3 Exclusions (error messages) Dialogs will not be counted if they are standard-error messages of functionality provided by Lotus

Notes. This is difficult to detect/decide. Indications are:

• The dialog’s title is „IBM Lotus Notes“

• The error message is verbalized in a different language than the application uses

• The error message is not required and specified or accepted by the user.

Furthermore functional error messages will not be counted as well. Those are part of the causing

function and not to be counted separately.

2.6 Platform-functionality The Lotus Domino platform provides several out-of-the-box features that partly accelerate the

development drastically – e.g. saving of restructured documents, replication among different

locations, encryption and signature, e-mail based workflows etc.

These cause the Lotus Domino platform’s advantageous delivery rate compared to different

platforms, since this functionality can be used directly without the need to implement it first.

Until empirical values are available the following rules apply:

• As soon as functionality provided by the platform is detected (either technically or by

consulting the developer) it will be protocolled in the size measurement documentation. This

functionality is counted in a separate sub-project and will be multiplied with a project reuse

multiplier of 0.

• If the implementation is to be carried out on a different platform, its realization is to be rated

separately and to be listed as additional effort. In this case the functionality again is counted in

a separate sub-project and will be multiplied with a project reuse multiplier of 0.

If the c.-AppScale-report “Feature Detection” is given it used as an aid to reveal Lotus-Notes-

specific features.

2.7 Multilingualism

Depending on the implementation of multilingualism the effort can either be moderate or

significant. It is not reasonable to determine the Function Points for each language.

Therefore the following standards are specified: The different texts will be administrated as string-

resources in the database. There is an entity to capture these. Changing the language is carried out

administratively within the database or personalized via an action in the menu / navigator.




Page:

Last edited:

12/23

24.10.2012

If and only if labels, help texts etc. are computed dynamically they are counted as data elements

once only. Another counting of the different language versions is not carried out.

2.8 Entities Definition of the entities:

• For each interactive input screen (i1/i2/i3) that is processed an entity has to be assigned

and counted.

• Multiple Functional Inputs can be assigned to the same entity.

• Profile-documents create an entity of their own but regarding “reads” and “writes” they

are deemed as system. 9

• The system-entity contains the following elements:

o User

o Date/time

o Symbols

o About-document

o Using-document

o Profile-document

2.9 Exclusions There are several elements that are excluded during the counting. These are e.g. tools that are

available but not requested explicitly:

• Document-Explorer

• Repl. Conflict Resolver

9 Whether data of profile documents is used within a form cannot be decided unambiguously without use of the

Domino Designer. Therefore these accesses will be counted simplified as “system”-accesses.




Page:

Last edited:

13/23

24.10.2012

3 Mapping of design-elements to BFC-types

Notes design BFC-type Remark

Tile Icon (q1)

Log-In (q2)

n=1, r=1 (system-entity) and

n=1, r=1 (system-entity)

create-entry Menu (q3) The application-specific menu-entries (excluding the default Lotus Notes-

entries) are counted, as long as these are visible (maximal characteristics).

n = Number of menu-entries (maximal characteristics)

r = Number of logical entities, generally 1 (System)

Context menu Menu (q3)

Action bar Menu (q3)

SmartIcon Icon (q1)

Navigator Menu (q3) Graphical menu

n = Number of menu-entries (maximal characteristics)

r = Number of logical entities, at least 1 (System)

View-groups (as sub-levels) are counted as a Selection List each.

Page -- Is counted via the underlying form, no separate counting.

Outline Menu (q3) n = Number of entries

r = generally 1

Each hierarchical level of the outline is counted as a discrete Menu.

View Browsing List

(q7)

The number of all (visible) columns is determined. Categorization and

summation are counted as well. Links and sorts are not counted.

n = Number of columns, sections, totals (c+s+t)

r = Number of logical entities, generally 1

the SELECT-formula should be checked in the Domino Designer to

identify other entities if applicable

Notation: c=Number of columns, s=Number of sections, t=Number of totals.

The action bar (once per entity) is counted as Menu (maximal

characteristics)

View (picklist) Selection List

(q4)

If a view is employed as a picklist it will counted as Selection List.

n = generally 1 (one column); r = generally 1 (one entity)

Notation: c=Number of columns, s=Number of sections, x=Number of sorts,

l=Number of links.

Folder Data Inquiry

(q5)

Treated like a view.

n = Number of columns

r = Number of logical entities, generally 1 (check SELECT-formula if

applicable)

Form 1/2/3

Functional

Input (i1/i2/i3

respectively

Form (o1)

Up to 3 functions: NEW / EDIT / DELETE

Default: Generally a Lotus Notes-form will be counted as 2-Functional Input

since most of the time the same form will be used to create and modify a

document. If the document can only be deleted in the view by using the

[Del]-key (no additional button), DELETE will not be counted.

If the form clearly is read-only then EDIT will not be counted.

Forms that only allow printing are counted as Form (o1).

The system-entity always is counted.

Embedded View Data Inquiry

(q5) /Browsing

List (q7)

Should normally already have been processed as view. If there are

embedded links count as Browsing List, otherwise Data Inquiry.

Embedded Form -- Has been processed by its overlying form and is not counted again (if




Page:

Last edited:

14/23

24.10.2012

obvious)

Drop Down List Selection List

(q4)

Generally:

n = Number of elements; r = 1 (system-entity)

Role in ACL Security

Routine (a1)

n = Number of roles; o = Number of operations, determined based on the

number of elements using this role. This is determined employing a search

in the Domino Designer.

About Dialog Data Inquiry

(q5)

Provided that the text is static:

n = 2+1, r = 1

Using Dialog Data Inquiry

(q5)

Provided that the text is static:

n = 2+1, r = 1

Mai-In DB Batch Record

IN (f2)

/Message IN

(f1)

If structured format is given, then Batch Record IN (f2); otherwise Message

IN (f1);

Default, if structure is unknown: n=5, r=1, w=1

if structure is known: n=Number of fields, r=1, w=1

Outbound Mail Batch Record

Out (t2)

/Message OUT

(t1)

If structured format is given, then Batch Record OUT (t2);

otherwise Message OUT (t1);

Default, if structure is known: n=5, r=1

if structure is known: n=Number of fields, r=1

Web-Service Message IN

(f1) /Message

OUT (t1)

If WSLD is present:

Provider=Message IN; Consumer=Message OUT

r+w=Number of methods, n=Maximum number of parameters

If WSDL is not present (and interface is relevant): analyze code

Periodic Agent Algorithmic

and

manipulation

Service, often

a2, a5 or t6.

n = Number of entities affected. This usually is deducible from the name

and the description and has to be recorded as an assumption.

o = Number of non-empty code-elements in the outline.




Page:

Last edited:

15/23

24.10.2012

Figure 1: Sample View

The figure above shows a sample view. The area marked as 1 shows an action bar that is used by

the views By Author, By Probe Server and By Type. The area marked as 2 shows a set of

SmartIcons. These are part of the Lotus Notes Client and therefore not part of the application.

Nevertheless it is possible to implement and add further SmartIcons as part of the application. The

function point analyst should keep this in mind. The list on the left is the navigation menu. Some

entries are used only to group entries that like the ones in the area marked as 3. Those are not

counted. Currently the view DDM Configuration/DDM Probes/By Type is selected for display as

can be seen in 4. The view itself is shown in the 5. Obviously there are at least 5 columns, 2 sums

and 3 sorts (although the sorts are not counted). The empty space between the sort of the Last

Modified By- and the Last Modified Date/Time-column looks suspicious. Clicking on that space

may show that there is another column.




Page:

Last edited:

16/23

24.10.2012

4 Explanation report

In the following a methodology will be described which on the one hand is based on FiSMA,

wherever applicable and on the other hand will use simple Domino Designer analyses to augment

the counting’s precision.

4.1 „Count Functionality“ In general Lotus Notes requires a certain way to implement functionality, which has to be detected

and examined functionally to assert a correct Function Points-counting. The following examples

are given to illustrate this:

4.1.1 Example “Visitor-Database” The “Visitor-Database” enables to store up to 10 visitors per appointment. The same data can be

recorded for each visitor, e.g. first name, last name etc. This data is stored in a form for a given

appointment. If a relational model would be used this would result in storing the visitors as an

entity and associating them via a 1:N-relationship with the appointments. Since Lotus Notes does

not employ a relational model, the data of the users are stored in the appointment entity.

Opposed to that the course of action will be ajar to the relational paradigm which does also reflect

the functional requirements more precisely. An entity is recorded for both the visitors and the

appointments. As customary with 1:N-relationships the entities on the N-side have a foreign key.

The fields of the visitors are not counted for the appointment-form, since they are determined

dynamically from the relationship. The counting will reflect this by incrementing the reads and

writes of the 2-Function Input (i2) of the appointment by one (write the foreign key to the user

respectively look-up visitor data for the visitor using the foreign key).

4.1.2 Example „ExampleCompany CRM“ A similar scenario is given by the application “ExampleCompany CRM”. One of the functional

requirements demands that that data can be imported via a SAP-interface. The technical

implementation imports this data into eight different databases that cache the data. Subsequently

it is imported from these. The number of Function Points of the technical implementation exceeds

the ones of the functional specification by far. The function point analyst is instructed to detect

such caching-strategies also known as Staging as far as possible and to count only functionality

that is required functionally.

4.2 User Interface

4.2.1 Web-interfaces detection Miscellaneous criteria have to be checked in order to decide whether an application has a web-

interface. This is necessary since Lotus Notes forms that have been engineered for Lotus Notes

only, can also be processed via the web, except this feature has been disabled explicitly. This

feature often is enabled unintentionally and should therefore not be counted.




Page:

Last edited:

17/23

24.10.2012

The following criteria are used to decide whether web-enablement functionality has to be

counted:

• Anonymous User in the ACL => web-interface available

• „Maximum Internet name and password“ (ACL/advanced) set to

o Editor => Default-value, no deduction possible based on this setting

o No Access / Depositor => no web-interface

o Different access-authorization => web-interface available

Figure 2: Anonymous User in ACL with Manager-rights

implies existence of web-interface

Figure 3: Maximum Internet name and password set to No

Access implies that no web-interface is given

4.2.2 Navigation All elements that are used to navigate the application are counted as Menu, even though strictly

speaking they might be Selection Lists. This simplifies the counting and the mapping significantly

and it makes no odds regarding the calculation.

4.2.3 Views / Embedded Views Views are counted as Browsing Lists (q7) in accordance with FiSMA. Provided that the list is not

clickable it is processed as Data Inquiry (q5). The columns that are visible form the basis of the

counting. Supporting columns are not counted. Hidden columns may be revealed using the

Domino Designer, most likely they will only be relevant in rare situations.

The action bar will be counted separately as Menu (q3). To avoid counting twice, for each entity

the maximal characteristic will be determined and counted. In practice this most likely can be

accomplished via grouping into optical distinct “view-clusters”.

The number of sections can be seen easily by pressing the “Expand All”-Button in the Domino

Designer (Shortcut (Shift +)).

To reveal columns that have no values in any row it is recommended to click the column headers

consecutively. This also reveals if such columns follow the last one with values entered.

The figure below shows a view with 6 columns (Total, Enabled, Last Modified By, Last Modified

Date/Time, unnamed column and Author), one section (Type), 3 sorts and two totals. Since the




Page:

Last edited:

18/23

24.10.2012

sorts are not counted this leads to a sum of n=6+1+2=9 for this view. The user did press on the

column between Last Modified Date/Time and Author to check whether the gap is consumed by

columns having no rows with values entered and if so how many of those.

The two buttons “Edit Document” and “Delete Document” belong to an action bar and are

counted separately as described above.

Figure 4: View with 9 data elements

Views that can only be displayed using links in other views are not counted.

4.2.4 Picklists Picklist-views are counted as Selection Lists (q4) or Browsing List (q7) depending if the view

contains clickable elements or not. Picklist-views are counted separately even if a “real” view with

the same design has been counted already.

4.2.5 Forms / Embedded Forms Typical Notes-forms and dialogs are classified as follows

• Data Inquiry (q5), if it is used only to display data

• Functional Input (i1/i2/i3), if it is used to create, create/edit, create/edit/delete documents

• Form (o1), if it is used only to as a printing-form

Since forms are used generally to create, display and edit a document they are typically

2-Functional Inputs (NEW, EDIT). The deletion generally is realized by marking the relevant

documents followed by pressing the [Del]-key. Since this does not lead to additional effort, the

DELETE-functionality will only be counted if a function is given in the dialog explicitly (button or

the like). If documents are flagged for deletion and the actual deletion is conducted downstream

(e.g. by a periodic agent), the DELETE will not be counted but only the accordant Database

Cleaning Routine (a5).

4.2.6 Sub-Forms Sub-forms are counted as a form’s component, except if they are explicitly specified differently or

are identifiable visually and apparently and are used in multiple forms. In that case they are

counted as a Data Inquiry (q5) or a Functional Input (x-FI) on their own.




Page:

Last edited:

19/23

24.10.2012

If the ratio is relevant an adaption of the re-use factor may carried out if applicable.

4.2.7 Pages, Outlines, Framesets Pages and outlines are counted generally as a component of the overlying dialog. Provided that

they are independent they are treated as Data Inquiry (q5) with n= Number of variable fields, r=1.

4.2.8 Actions For each action that has to be counted one different coherent element has to be counted. If no

special BFC-type can be assigned at least one Other Routine (t6) has to be listed. The default is 1,1.

The function point analyst can choose different values, if he and the user can justify these. Try to

identify actions, which are requested by the used rather than added “because it’s a quick change”.

The following examples should illustrate standard mappings:

• „Save“, „Save & close“, „Edit“ � appropriate Functional Input (i1/i2/i3)

• “Print” � Generation Dialog (q6)

• “Forward” � Message OUT (t1)

4.2.9 Database-properties Potentially integral functionalities of an application are provided out-of-the-box by certain settings

in the system-properties. These have to be counted. The following settings have been identified

and rated:

4.2.9.1 „Space Savers“ within the replication-settings

The option “Remove documents not

modified in the last (days) xx” is a Database

Cleaning Routine a5 (n=1(*), since all entities

are affected and o=1).

Figure 5: Space savers

4.2.10 Tooltips Tooltip-holders are not counted generally. The tooltip is treated as a Data Inquiry (q5) only if

evidently multiple variables are contained. Static tooltips are not counted.




Page:

Last edited:

20/23

24.10.2012

4.3 Security Routines

4.3.1 Usage of roles Lotus Domino allows to hide, to restrict the

access to or to implement supplementary

functionality for individual sections, actions,

navigation-elements etc. depending on the

roles that the user holds (Hide When

Formulas).

Identification of the used roles and thereby

of additional Security Routines (SR) conform

to FiSMA is implemented as follows. The

basic idea is that each role represents an

operand in the security concept whereas

each employment of such a role is considered

an operation restricting the accessibility or

visibility. This course of action has the benefit

that the set of rules on the one hand is

lightweight, easing an accurate and

unambiguous counting, while on the other

hand does capture the security concept as a

whole.

The procedure to estimate the numbers of

operands and operations is carried out in two

ways:

• The list of the defined roles can be

taken from the Access Control List

(ACL).

• Within the Domino Designer each role

is searched via the shortcut key

combination [Ctrl] + [H]. Thereby all

occurrences in the design where the

role is used are identified. Entries in

the database properties are not

counted just as entries in fields that

obviously do not belong to the

application’s functionality (e.g. fields

added by development tools).

Figure 6: Search for a role defined in the ACL

Figure 7: Search results

4.3.2 Reader-/Author-fields Reader- and Author-fields are not counted separately. Their occurrences are already covered by

the course of action above.




Page:

Last edited:

21/23

24.10.2012

4.3.3 View-/Form-properties The usage of roles in the View-/Form-properties is not counted separately. Their occurrences are

already covered by the course of action above.

4.4 Interfaces If no specification of the database is at hand the interfaces can be determined to a certain extent

using the Domino Designer, the Domino Directory or code analysis.

If the c.-AppScale-report “Interface Indication” it will be used as an aid to reveal interfaces.

4.4.1 Mail-In DB The Domino Directory can be examined to

check whether a database provides a Mail-In

interface. In that case a Batch Records IN (t2)

is counted respectively a Message IN (f1) if it

operates in real-time.

To check whether a database has a Mail-In

interface open the names.nsf on the

appropriate server and check if the database

is contained in the view:

Configuration > Messaging > Mail-In

Databases and Resources > by Organization

Figure 8: The Domino Directory showing all Mail-In Databases




Page:

Last edited:

22/23

24.10.2012

4.4.2 Outbound Mail The Domino Designer is used to the search

the design of the application for the given

search strings

• @MailSend(

• @Command([MailSend])

LotusScript- or Java-calls cannot be analyzed

without detailed code examination.

Outbound Mails are counted as Interactive

Output Function (o3 for e-mail/text

messages) when the data is sent in real-time.

If the format of the message is not given, that

is the values for n and r cannot be

determined the default values (n=5, r=1) are

employed.

Figure 9: Search for outbound mail-interfaces in the Domino Designer

4.4.3 Databases Database-interfaces are counted as Message

IN (f1) or Batch Records IN (f2). A rough

identification of the interfaces can be done

by searching the application-design for

certain search strings. Provided that no

specification of the interfaces is present (ER-

diagram or the like) a detailed counting can

only be achieved conducting an analysis of

the code and the table-design of the target

application.

The quick-search results in an indication

whether an interface to another database

exists.

Figure 10: Search for interfaces in the Domino Designer

4.5 Code The delivery rate per Function Point generally includes the effort for implementing the required

business logic (@Commands, LotusScript). Therefore the source-code of an application is not

counted.

This applies also for agents, except complex backend-functionality of significant size is used. If no

detailed specification is at hand the associated Function Points can only be determined via a

detailed code analysis or by interviewing an application’s expert (representing the functional user

requirements).




Page:

Last edited:

23/23

24.10.2012

The function point analyst may decide to do so and count an Algorithmic and Manipulation Service

(an) if he can justify this. The justification has to be documented.

5 Checklists

5.1 Complete Counting Checklist # Step Remark Copy database to a server

Configure authorizations All functionality must be visible

Configure database Database must be “usable”

Count database in Lotus Notes

Count actions that are available in

the Notes action-bar only

Count roles

Count periodical agents

Count entities Count profile-documents also

Count database in web browser Check (functionally) whether web interface is an integral

part

Count interfaces

Documents

c.-SAMM for Lotus Notes - DASMAdasma.org/contray/media/pdf/c.-SAMM-FSM_for_Notes... · 0.8 21.03.2012 Michael Otto Review by Manfred Seufert, Mediaan ... Cedros developed the toolset