COSMIC Sizing Forums COSMIC Size measurement Software configuration and implementation


This topic contains 4 replies, has 3 voices, and was last updated by  Selami Bagriyanik 4 months, 3 weeks ago.

  • Author
  • #5822

    Islam Bayraktar


    Can you advice any article or case study about the topic.
    How should we apply COSMIC for enterprise enterprise software configuration and also implementation of such products (like PPM tools, TFS, Service Manager etc)? How to map COSMIC to this and calculate CFP? If possible with some examples.
    Configuration can be seen as a special kind of design activity, where the final product is built of a predefined set of
    component types (forms, fields, workflows, automation of some operations etc) and attributes, which can be composed conforming to a set of corresponding constraints. Also in additional it includes some parts of development like creating views/web services/sql etc for different uses and component types.

    Thanks and Regards,

  • #5823

    Frank Vogelezang

    Dear Islam,

    Software configuration and implementation behave very similar to regular software development, but the way it is documented and the effort needed for implementation differ greatly. Since this type of software is implemented from predefined components often there is no description of the Functional User Requirements as required for a detailed COSMIC measurement. Usually business processes are available to which the predefined processes are mapped. You can get a size measure in COSMIC from the processes using an approximation technique. In 2006 I have written an article on the subject:Using COSMIC for sizing, estimating and planning in an ERP environment.

    On the current available techniques you can read the following guideline Early or Rapid for COSMIC functional size measurements.

    I hope this helps.

    Regards, Frank

  • #5824

    Selami Bagriyanik

    Dear Islam,
    As Frank pointed out, software configuration (For example, vanilla ERP/CRM products such as, Oracle ERP or Siebel CRM) can be considered as a special case of software development. Software is implemented using first, 2nd, 3rd, 4th, etc. generation programming languages/IDEs. Configuration can be considered for example as the 5th generation program design. Furthermore, Cosmic FP is a functional requirement measurement methodology which is independent of technical design and implementation method.

    However your challenge will be capturing the requirements in terms of functional processes which COSMIC expects. I believe you can overcome this potential issue by defining the requirements as for example effected use cases. We apply the method to configuration cases in Turkcell (A telecommunications company in Turkey) as well.

    I hope this helps. Please do not hesitate to contact me for further information.

    Selami Bagriyanik

  • #5859

    Islam Bayraktar


    Thanks guys for you feedback.
    I am agree methodology should be independent on implementation method (coding or configuration). As we have data movements (E, X, R, W), use cases, functional processes independent on technology. But I have a doubt about justness of that…

    Let’s see. I want to go through simple example of implementation in enterprise configurable software.

    For example, new workflow (user approval and execution steps), form linked to workflow with fields and logic (rules) between fields and data.
    Workflow: 3 steps (2 of them user approval, 1 execution step – means some calculation based on entered data).
    Form: 4 fields (3 of them user’s entry, 1 calculated based on other field).
    All fields combobox fields (these fields created by configurator manually or coding some query).

    Let’s call it very primitive Bug demand process. Configuring here will be mix of 5th generation of design with some coding in several places.
    Users creates Bug demand. Enters Application, Module, Description. Assigned to Group field will be calculated based on Application/Module data (rule: read application/module find 1’st level support group in the storage).
    0. step: end user creates Bug demand
    1. step: bug demand goes to assigned to group, completed or escalate to next level
    2. step: execution in case of escalation, based on application/module calculate 2’nd level support group, re-assigned bug demand to that group, forward to 1 step)
    3. step: end user approves solution and close the bug, if not sends back to 1’st step with a note.

    CFP calculation:
    0. step: 1 E -> 1 cfp, calculation for assigned group (1 R, 1 X) -> 2 cfp
    1. step: 1 E (approval or escalation) -> 1 cfp
    2. step escalation: 1 R, 1 X (re-assigning to next level by code) that’s 2 cfp
    3. step: 1 E (approval), 1 E (for the note), so that’s 2 cfp

    Total: 8 cfp.
    Is that correct?

    Thanks & Regards,

  • #5884

    Selami Bagriyanik

    Dear İslam,
    it seems your steps correspond to Cosmic functional processes (in business terms, usecase). But we need to talk on the example you’ve given in more detail to prevent misunderstandings. Could you please drop me an e-mail to arrange a quick short call.

    Best regards.

You must be logged in to reply to this topic.