Applications, Releases, Count Sessions

I need a better understanding of how SCOPE handles Project vs. an Application. SCOPE appears to link sessions to projects and not applications. Does this mean that if my new development application is named "Dispatch & Billing Solution", then I would create a project with the same name and link the count sessions to this? If this is the case, when would the project name be different than the Application name?

The development Project name and Application name - are often the same, however for clarity we would usually choose to distinguish them ie. "Dispatch and Billing Development Project" and "Dispatch and Billing Version 1.0". But the same name is OK. SCOPElinks a project to a count session rather than an application since often in an organization there will be a "project" that will impact many applications. eg. the project to introduce Goods and Services Tax will impact many applications.

Using the Project name SCOPE allows you to identify all the counts that were specifically impacted for that project. If the project is for only one application then that is OK, just link it to the Count Sessions that the project that will be impacting.

The other common situation that SCOPE can handle is when a Release of an application may have many change requests, each of which is a "Project". This allows all the effort data to be collected specifically for the Project and the counts that it impacts. You may have not noticed but the fields collected for Project are the mandatory fields that the International Benchmarking Standards Group (ISBSG) collects. SCOPE allows you to collect the data for their repository in their format. SCOPE will aggregate the Project Size across many applications and many count Sessions and report the total Project Size and it Project Delivery Rate (PDR) in hours per function point.

How is a Release different to a Project?

SCOPE uses the concept of 'Release' because many organizations will have a production version of an application and then have periodical releases for the application. Within the Release period they will have multiple 'Change Requests' (CRs) that they are required to size and estimate. These CRs may come from one or more Projects. SCOPE allows the project manager to individual size Change Requests using 'Count Sessions'.

At any time the project manager can determine the:

  1. Net size of the Impacted functions for the Release (ie. all CRs)
  2. Individual size of each CR
  3. Net baseline size of the Release
  4. Size of the 'rework' that has occurred when multiple CRs impact the same function during the release period

Why does SCOPE have the concept of 'Production' Releases and 'Work in Progress' Releases?

SCOPE has the concept of an application being built by a development project. The first release of the application is a "work in progress" release and its count session records all the added functionality developed by the project team. Each count session during the development life cycle is linked to the Development Project. For the first count of a Release, all the functions are listed as being 'added'. Subsequent changes to the SCOPE of the Development Project can be recorded as other Count Sessions. This provides an 'audit' trail of changes and allows these changes to be individually sized. These Count Sessions may be linked to other Projects or the Development Project.

If at any point you want to 'snap' shot the status of the functionality within a release at a point in time, then just take of copy of it and store it in 'others'.

At the implementation of the Release, use the 'Update to Baseline' to store in the Production Releases. Then if more CRs are required to be counted, set up a new Work in Progress Release and just copy the production version into the new version and start a new count session.

For the initial count of my new development project do I need to create a count session or can I simply input the information for a the Release?

This is your choice. If you do not want the new processes or data groups to have an 'impact type' then select the option "no session" from the status bar at the bottom of the screen. For documentation purposes I would recommend that you create a count session any time that you do a count. This records all the aspects of the count, eg. who did it, the date, documentation referenced etc. . For a development project, if you do your first count using a "session" then all the functions are recorded as "added". Subsequent change requests can then be recorded and will be reported as "rework".

How will support be handled for the product? If I have questions regarding the use of it or if I encounter bugs, etc. Is there a support line? E-mail?

Yes, we provide e-mail support by. E-mail support is free for the new purchasers and anyone with an ongoing maintenance contract. Our support office will respond to your queries within 48 hours of your request.

Phone support is also available on request - please contact us for our charge rates.