11 SCOPE counts are more understandable by the Business Users
SCOPE‘s way of recording functional size takes into account the way we develop software today i.e. It recognises in the way it structures its Applications, Release, Projects and Counts such that :
- a users business initiative (Project) may have many change requests that impact one or many different software applications and sometimes have more than one CR that impacts a single Release of one of the applications
- software tends to be developed on a Release based approach rather than an approach where each Change Request resulting in a new production version of the software
- each Release may have one or more Change Requests belonging to either same or different projects. These Change Requests need to individually sized since they contribute to different projects and are often run by different teams and approved independently
- SCOPE counts can be dynamically adjusted to reflect what is happening in the development team and the business so project size can be reported as an aggregate of the CRs for input into estimates and project counts can be cancelled or postponed without corrupting the integrity of the baseline
- SCOPE structure can provide the corporate model to graphically display the growth of the organisations software portfolio
SCOPE enables a Project to record multiple Impacts across multiple Applications and aggregate Function Point size, at Change Request, Application Level, Release Level and at Project Level.
SCOPE can record multiple Impacts from multiple projects on an Application concurrently and be able to maintain and report the different Project Impacts independently.
SCOPE’s flexibility allows it to respond to changing project implementation decisions by being able to record the Project Impact on an Application AND be able to decide to not apply it, or to remove it or to hold it over to be applied again at a later date when the project is approved or restarted.
|Benefits of SCOPE for Modelling the ‘real world’ of IT |