usecasepoints -ipd
TRANSCRIPT
-
8/7/2019 UseCasePoints -IPD
1/15
Total Effort for Software excluding PM. 256 hours
Total Effort for Software including PM. 282 hours
Effort Req Des Dev Testing
PM
Solution Arch 1
Tech Lead 1 1 1
Senior Dev 3 3 2Junior Dev
BA 1 1
Tester 1 4
% Distribution of Effort across SDLC 10 20 40 30
UCP Break Up in hours 26 51 103 77
No of resources 2 5 4 8
Schedule in hours 13 10 26 10
Schedule in days 2 1 3 1
Cost in Dollars 733 2260 3237 2030
Total Schedule assuming serial delivery in days (Waterfall) 7 days
Assuming 20% compression in schedule by fast tracking/crashing 6 days 0 months
TotaL Cost for Development 9,641 $
-
8/7/2019 UseCasePoints -IPD
2/15
PM Total
1 1382 54
965 94
2384 52
3125 250 20
891 40
895 17
10
26
1
26
3
1382 9641
Rate in $ perhour
-
8/7/2019 UseCasePoints -IPD
3/15
-
8/7/2019 UseCasePoints -IPD
4/15
Technical Factor Multiplier
1 2 3
2 1 4
3 1 4
4 1 4
5 1 2
6 Installation Ease 0.5 2
7 Usability 0.5 4
8 2 4
9 Easy To Change 1 4
10 Highly Concurrent 1 3
11 Custom Security 1 2
12 1 2
13 User Training 1 3
Calculated TCF 1.05
RelativeMagnitude(Enter 0-5)
Distributed System
Required
Response Time IsImportant
End UserEfficiency
Complex InternalProcessing
Required
Reusable CodeMust Be A Focus
Cross-Platform
Support
Dependence OnThird-Party Code
-
8/7/2019 UseCasePoints -IPD
5/15
Description
The architecture of the solution may be centralized or single-tenant , or it
may be distributed (like an n-tier solution) or multi-tenant. Higher numbersrepresent a more complex architecture.
The quickness of response for users is an important (and non-trivial) factor.For example, if the server load is expected to be very low, this may be atrivial factor. Higher numbers represent increasing importance of responsetime (a search engine would have a high number, a daily news aggregatorwould have a low number).
Is the application being developed to optimize on user efficiency, or justcapability? Higher numbers represent projects that rely more heavily on theapplication to improve user efficiency.
Is there a lot of difficult algorithmic work to do and test? Complex algorithms(resource leveling, time-domain systems analysis, OLAP cubes) have
higher numbers. Simple database queries would have low numbers.
Is heavy code reuse an objective or goal? Code reuse reduces the amountof effort required to deploy a project. It also reduces the amount of timerequired to debug a project. A shared library function can be re-usedmultiple times, and fixing the code in one place can resolve multiple bugs.The higher the level of re-use, the lower the number.
Is ease of installation for end users a key factor? The higher the level ofcompetence of the users, the lower the number.
Is ease of use a primary criteria for acceptance? The greater theimportance of usability, the higher the number.
Is multi-platform support required? The more platforms that have to be
supported (this could be browser versions, mobile devices, etc. orWindows/OSX/Unix), the higher the value.
Does the customer require the ability to change or customize theapplication in the future? The more change / customization that is requiredin the future, the higher the value.
Will you have to address database locking and other concurrency issues?The more attention you have to spend to resolving conflicts in the data orapplication, the higher the value.
Can existing security solutions be leveraged, or must custom code bedeveloped? The more custom security work you have to do (field level,page level, or role based security, for example), the higher the value.
Will the application require the use of third party controls or libraries? Like
re-usable code, third party code can reduce the effort required to deploy asolution. The more third party code (and the more reliable the third partycode), the lower the number.
How much user training is required? Is the application complex, orsupporting complex activities? The longer it takes users to cross the suckthreshold (achieve a level of mastery of the product), the higher the value.
-
8/7/2019 UseCasePoints -IPD
6/15
-
8/7/2019 UseCasePoints -IPD
7/15
Description
How motivated is your team? Higher numbers represent more motivation.
How much experience does your team have working in this domain? Thedomain of the project will be a reflection of what the software is intended toaccomplish, not the implementation language. In other words, for aninsurance compensation system written in java, you care about the teamsexperience in the insurance compensation space - not how much javatheyve written. Higher levels of experience get a higher number.
How much experience does your team have with the application. This willonly be relevant when making changes to an existing application. Highernumbers represent more experience. For a new application, everyonesexperience will be 0.
How much experience does your team have at OO? It can be easy to forgetthat many people have no object oriented programming experience if you
are used to having it. A user-centric or use-case-driven project will have aninherently OO structure in the implementation. Higher numbers representmore OO experience.
How knowledgeable and capable is the person responsible for therequirements? Bad requirements are the number one killer of projects - theStandish Group reports that 40% to 60% of defects come from badrequirements. Higher numbers represent increased skill and knowledge.
Changes in requirements can cause increases in work. The way to avoidthis is by planning for change and instituting a timing system for managing
those changes. Most people dont do this, and some rework will beunavoidable. Higher numbers represent more change (or a less effectivesystem for managing change).
Note, the multiplier for this number is negative. Higher numbers reflect teammembers that are part time, outside consultants, and developers who aresplitting their time across projects. Context switching and other intangiblefactors make these team members less efficient.
This multiplier is also negative. Harder languages represent highernumbers. We believe that difficulty is in the eye of the be-coder (groan).Java might be difficult for a fortran programmer. Think of it in terms ofdifficulty for your team, not abstract difficulty.
-
8/7/2019 UseCasePoints -IPD
8/15
Multiplier
1 Simple 5 0
2 Average 10 0
3 Complex 15 0
Calculated UUCP 0
Individual Use Cases Multiplier1
2
3
2
3 Manage Patient Details
4
3
4
5 Manage Documents
4
5
6
5 Manage Payments
6
7
6
7 Manage Patient Transfer
8
7
8 Manage Services
9
Reporting
Manage Clinical History
Manage doctor's Notes
8
9 Manage Services
UnadjustedUse Case Points
Number of UseCases
-
8/7/2019 UseCasePoints -IPD
9/15
-
8/7/2019 UseCasePoints -IPD
10/15
Manage Empolyee details
Manage Roles
Map User Roles
10 Complex
Insert additional rows above this row and cop
Assumptions
1 Assuming we have only 8 modalities as mentioned above.
1
-
8/7/2019 UseCasePoints -IPD
11/15
Description
Simple Use Case - up to 3 transactions.
Average Use Case - 4 to 7 transactions.
Complex Use Case - more than 7 transactions.
Use Case Name Actor ResponsibleLogin Receptionist
Search Consultant Receptionist
View Consultant Receptionist
Assign Consultant Receptionist
Create Patient Receptionist
Edit Patient Receptionist
Search Patients Receptionist
View Patient Receptionist
Delete Patients Receptionist
Create Patient Document Receptionist
Edit Patient Document Receptionist
View Patient Document Receptionist
Delete Patients Documents Receptionist
Create Bill Receptionist
Edit Bill Receptionist
View Bill Receptionist
Delete Bill Receptionist
Admit OPD Patients Receptionist
Transfer Patients From One Bed to Another Receptionist
Dischage Patients Receptionist
Add Services to Patients Receptionist/
Edit Services Receptionist
Delete Services Receptionist
View Assigned Services Receptionist
View Daily Cash Collection Report Receptionist
View Patient Discharge List Receptionist
View Wardwise Patient List Receptionist
View Notice Board List Receptionist
Create Clinical history Consultants
View Clinical History ConsultantsCreate Notes Consultants
View Notes Consultants
Delete Notes Consultants
Schedule Surgery Reciptionist/Floor Manager
Search Ward / Search Room /Search Bed / allocate Reciptionist/Floor Manager
Search Consultant/Assign Consultant Reciptionist/Floor Manager
-
8/7/2019 UseCasePoints -IPD
12/15
Search PharmacyItems/ Allocate Pharmacy Items Reciptionist/Floor Manager
Search Modality / allocate Modality Reciptionist/Floor Manager
Create Misc. Services Admin
Edit Mis Services Admin
View Misc. Services Admin
Delete Misc Services AdminCreate Modalities Admin
Edit Modalities Admin
View Modalites Admin
Delete Modalites Admin
Create Ward Admin
Edit Ward Admin
View Ward Admin
Delete Ward Admin
Create room Admin
Edit Room Admin
View Room Admin
Delete Room AdminAssociate with Ward Admin
Create Bed Admin
Edit Bed Admin
View Bed Admin
Delete Bed Admin
Associate with Room Admin
Admin
Create Operation Theatre Admin
Edit Operation Theatre Admin
View Operation Theatre Admin
Delet Operation Theatre AdminCreate Site Admin
Edit Site Admin
Delete Site Admin
View Site Admin
Create Country Admin
Edit Country Admin
Delete Country Admin
View Country Admin
Create State Admin
Edit State Admin
Delete State Admin
View State AdminCreate City Admin
Edit City Admin
Delete City Admin
View City Admin
Create Pharmacy Item Admin
Edit Pharmacy Item Admin
Delete Pharmacy Item Admin
-
8/7/2019 UseCasePoints -IPD
13/15
View Pharmacy Item Admin
Admin
Create Employee Admin
Edit Employee Admin
Delete Employee Admin
View Employee AdminCreate Roles Admin
Edit Roles Admin
View Roles Admin
Delete Roles Admin
Create Map User to Roles Admin
Edit Map User to Roles Admin
Delete Map User to Roles Admin
View Map User to Roles Admin
y the cell values to automatically update the counts of actors by type
-
8/7/2019 UseCasePoints -IPD
14/15
Actor Summary Multiplier
1Simple
1
0
2 Average 2 0
3 Complex 3 3
Calculated AW 9
Individual Actors Multiplier 1 Complex 3 Receptionist
2 Complex 3 Floor Manager
3 Complex 3 Consultants
Admin
Insert additional rows above this row and copy the cel
Number ofActors
-
8/7/2019 UseCasePoints -IPD
15/15
Description
Actor Name
l values to automatically update the counts of actors by type
Simple actors are other systems that communicate with your software via apre-defined API. An API could be exposed through a dll, or as a REST,SOAP, or any web-service API or remote procedure call (RPC). The keyelement is that you are exposing interaction with your software through aspecific, well-defined mechanism.
Average actors can either be human beings interacting in a well definedprotocol, or they could be systems that interact through a more complex orflexible API.
The original definition of complex actors specifies that users who interactwith the software through a graphical user interface are complex actors.While that is true, the same classifcation should apply to users who interactwith the system in unpredictable ways. An AJAX interface that exposesmore of the underlying application (and data stores) than would beavailable through a rigid protocol might introduce similar complexity.