Table :- EI for the update customer While counting EI I have seen many people multiplying it by 3.That means we are going to do all CRUD functionality (ADD, UPDATE, and DELETE).This is not fair as it just shows laziness of the Cost estimation team. Here the customer screen has add and update. I can say the 2 * 6 that's = 12 FP for this EI customer. But later when some refers to your FP sheet he will be completely lost. Following are rules to recognize EO: - Data should cross application boundary and it should involve complex logic. Credit card check process can be complex as the credit card API complexity is still not known. Data that is credit card information crosses from credit card system to Customer system. EO check credit card Description Number of DET Number of RET One DET Credit Card number and one RET credit 1 1 card itself. Note if there are no RET we count default as one. Look for RET counting rules defined in previous section. So according to the above ranking table Total function 4 Table :- EO to check the credit card Following are rules to recognize EQ: - It’s a dynamic elementary process in which result data is retrieved from one or more ILF or EIF. For editing the customer we will need to retrieve the customer details. In this EP some input request has to enter the application boundary. The customer code is inputted from the same screen. Output results exits the application boundary. The customer details is displayed Page 55 of 215
while the customer is editing the customer data. EQ does not contain any derived data. The above customer data which is displayed does not contain any complex calculations. EQ Display Customer Edit Information Description Number of Number of FTR DET There are 5 DETs to be retrieved Customer Code, Customer Name, Credit Card number, Active, Customer Address. Only customer details and 5 2 customer address will be referenced. So according to the above ranking table Total function 3 Table :- EQ to display customer edit So now, let’s add the total function point got from above tables: Function Point Section Name Counted ILF Customer EO Credit Card check system 4 EIF credit card information 5 EI Customer (Add and 12 update) EQ display customer edit 3 information Total Unadjusted 31 Function Points Table :- Total of all function point So unadjusted function point comes to 31.Please note we have said this as Unadjusted function as we have not accounted other variance factor of project (Programmers leaving job, Language we will use, what architecture etc etc). In order to make it adjusted function point, we have to calculate and tabulate the GSC and come out with the VAF. GSC Value(0-5) Data communications 1 Distributed data processing 1 Performance 4 Heavily used configuration 0 Transaction rate 1 On-Line data entry 0 End-user efficiency 4 On-Line update 0 Page 56 of 215
Complex processing 0 Reusability 3 Installation ease 4 Operational ease 4 Multiple sites 0 Facilitate change 0 Total 22 Table :- GSC VAF = 0.65 + ((sum of all GSC factor)/100). = 0.65 + (22/100) = 0.87. This factor affects the whole FP like anything, be very particular with this factor. So now, Calculating the Adjusted FP = VAF * Total unadjusted FP = 0.87 * 31 = 26.97 = rounded to 27 FP. Now we know that the complete FP for the customer GUI is 27 FP. Now calculating the Efficiency factor, we say that we will complete 3 FP per day that is 9 working days. So, the whole customer GUI is of 9 working days (Note do not consider Saturday and Sundays in this). I know upper manager people will say make it 7 FP per day and over load the programmer. That’s why programmer works at night. Considering SDLC (System Development Life Cycle) Before reading this section please refers to different SDLC cycles in previous chapters. The main intention of introducing this section is because estimations are heavily affected by which software life cycle you follow. Because deliverables change according to SLDC model the project manager chooses for the project. Example for waterfall model we will have Requirement documents, Design documents, Source code and testing plans. But for Prototyping models in addition to the documents above we will also need to deliver the Rough prototype. For build and fix model we will not deliver any of the documents and the only document delivered will be source code. So according to SDLC model deliverables change and hence the quotation. We will divide the estimation across requirement, design, implementation (coding) and testing .In what way the estimation has to divide across all deliverables is all up to the project manager and his plans. Phase Percentage distribution effort Requirements 10% of total effort Design Phase 20% of total effort Coding Total effort given by unadjusted FP Testing 10% of total effort Table :- Phase wise distribution of effort The above sample is total 100 % distribution of effort across various phases. But as said it up to the project manager to change according to scenarios.Ok now from the above function point estimation the estimation is 9 days let’s try to divide it across all phases. Page 57 of 215
Phase Percentage distribution Distribution of man/ effort days across phases Requirements 10 % of total effort 0.9 days Design Phase 20 % of total effort 1.8 days Coding 100 % as given by the 9 Days unadjusted FP Testing 10 % of total effort 0.9 days Total 12.6 Days Table :- Phase wise effort distribution of man days The above table shows the division of project man/days across project. One of the important point to note is the estimation derived from unadjusted FP is 9 days and percentage of that man days is distributed across the total SDLC cycle. But for execution we have taken the 100 % of the man days derived from unadjusted FP. Any estimation technology (COCOMO, Use case points , FP , SMC) gives you total estimation of execution and not for other activities like documentation etc. So we have allocated total man days derived from unadjusted FP in coding and then percentage of it is distributed across other phases. Now let’s put down the final quotation. Just a small comment about test cases. Total number of Test Cases = (Function Point) raised to power of 1.2.This is as suggested from caper Jones. Number of Acceptance Test Cases = 1.2 * Function Points 20-25 % of total effort can be allocated to testing phase. Test cases are non -deterministic. That means if test passes it takes “X” amount of time and if it does not then to amend it take “Y” amount of time etc etc. Final Estimation One programmer will sit on the project with around 1000 $ salary / Month. So his 12.6 days salary comes to 290 dollars approx. The upper quotation format is in its simplest format. Every company has his quotation format accordingly. So no hard and fast rule of quotation template. But still if interested http://www.microsoft.com/mac/resources/ templates.aspx?pid=templates has good collection of decent templates. XYZ SOFTWARE COMPANY Page 58 of 215
To: TNC Limited, Western road 17, California. Quotation number: 90 Date: 1/1/2004 Customer ID: Z- 20090DATAENTRY Quantity Description Discount Taxable Total 1 Customer Project 0% 0% 466 dollars Quotation Valid for 100 days Goods delivery date with in 25 days of half payment Quotation Prepared by: - XYZ estimation department Approved by : - SPEG department XYZ. Table – Final bill CustomerSampleFP.xls is provided with the CD which has all estimation details which you can refer for practical approach. Note: - In this book we have shipped a complete book “How to prepare software Quotation”. This free E-book basically explains in detail manner other estimation technology widely used in projects. GSC Acceptance in Software industry GSC factors have been always a controversial topic. Most of the software companies do not use GSC, rather than they base line UAFP or construct there own table depending on company project history. ISO has also adopted function point as unit of measurement, but they also use UAFP rather than AFP. Let’s do a small experiment to view relationship between FP, AFP, GSC and VAF. In this experiment we will assume UAFP = 120 and then lot graph with GSC increment of five. So the formulae is VAF = 0.65 + (GS/100). Here’s the table with every five incremental values in formulae and plot. FP GSC 78 0 84 5 90 10 96 15 102 20 108 25 114 30 120 35 126 40 132 45 138 50 144 55 150 60 156 65 Page 59 of 215
162 70 Table :- GSC acceptance Figure 1.23:- FP versus VAF The following are the observation from the table and plot: - Graph is linear. It also captures that nature of complexity is linear. If the GSC value is zero then VAF is 0.65. So the graph starts from UAFP*0.65.GSC = 35 AFP = UAFP. So the VAF = 1. When GSC <> 35 then AFP > UAFP. That means complexity increases. Readers must be wondering why 0.65? There are fourteen GSC factor from zero to five. So the maximum value of VAF = 0.65 + (70/100) = 1.35. In order that VAF does not have any affect i.e. UAFP = FP VAF should be one. VAF will be one when GSC is 35 i.e. half of 70. So in order to complete value “1” value “0.65” is taken. Note value is 0.35 when GSC is 35 to complete the one factor “0.65” is required. But following is the main problem related to GSC. GSC is applied throughout FP even when some GSC does not apply to whole function points. Here’s the example to demonstrate GSC problem. Page 60 of 215
Let’s take 11th GSC factor “installation ease”. The project is of 100 UAFP and there is no consideration of installation previously by client so the 11th factor is zero. GSC with installation ease with ZERO GSC Value(0-5) Data communications 1 Distributed data processing 1 Performance 4 Heavily used configuration 0 Transaction rate 1 On-Line data entry 0 End-user efficiency 4 On-Line update 0 Complex processing 0 Reusability 3 Installation ease 0 Operational ease 4 Multiple sites 0 Facilitate change 0 Total 18 Table : GSC with installation ease zero VAF = 0.65 + (18/100) = 0.83. So the FP = 100 * 0.83 = 83 Function Points. But later the client demanded for full blown installation for the project with auto updating when new version is released. So we change out GSC table with installation ease to 5. GSC with installation eases “5” GSC with installation ease with FIVE GSC Value(0-5) Data communications 1 Distributed data processing 1 Performance 4 Heavily used configuration 0 Transaction rate 1 On-Line data entry 0 End-user efficiency 4 On-Line update 0 Complex processing 0 Reusability 3 Installation ease 5 Operational ease 4 Multiple sites 0 Facilitate change 0 Total 23 Page 61 of 215
Table :- GSC with Installation ease 5 So VAF = 0.65 + (23/100) = 0.88 so the FP = 100 * 0.88 = 88. The difference is of only 5 FP which from no way a proper effort estimate. To make an auto updation for a software versioning can no way be done in 5 function points , just think downloading new versi on, deleting the old version , updating any database structure changes etc etc. So that’s the reason GSC is not accepted in software industry. Best ways is baseline you’re UAFP and make your estimation on base of UAFP. Enhancement Function Points Major software project fail not because of programmer’s or project managers but due to moody and changing customers. In one of our huge projects we had good programmers, very enthusiastic. The project started of well but customer called ten times in a day to change something or other. Believe me programmers get pissed if the customer is changing his plans every fortnight. Well from this book point of view we have to evaluate this changes which can be addition or deletion of requirements. Function point group has come out with a methodology called as “Enhancement Function Points”. Down is the formulae Formulae of EFP (Enhanced Function Points) = (ADD + CHGA) * VAFA + (DELFP) * VAFB ADD: - This is new function points added. This value is achieved by counting all n ew EP (Elementary process) given in change request. CHGA: - Function points which are affected due to CR. This value is achieved by counting all DET, FTR, ILF, EI, EO and EQ which are affected. Do not count elements which are not affected. VAFA: - This is VAF factor which is because of CR. Example previously the application was desktop and now is changed to web so the GSC factor is affected. DELFP: - When CR is for removing some functionality this value is counted. It’s rare that customer removes functionalities (at least in India), but if they ever estimator has to take note of it by counting the deleted elementary process. VAFB: - Again removal affects Value added factor. Once we are through with calculating enhanced function points, it time to count total Function points of the application. Total Function points = [UFPB + ADD + CHGA] – [CHGB – DELFP] Page 62 of 215
UFPB: - Function points previously counted before enhancement. ADD: - Newly added functionality which leads to new function points after enhancements. CHGA: - Changed function points counted after enhancements. CHGB: - Changed function points before enhancements. DELFP: - Deleted function points. Enhancement function points is not covered from practical angle in this book and is left to the user’s as exercise. CR (Change request) is covered in more detail in Change request chapter. Function point template explanation In order to use FP in our project in easy fashion we will be using function point excel template to automate our estimation. In both Jobsite and chat application you can find the estimation sheet. When you open the sheet you can see the below section as shown in figure below. Total Estimation has the full consolidation of the estimation.ILF, EIF, EO, EQ, EI and GSC serves as an entry she et for all the necessary inputs. Figure 1.25 :- Different sections in FP template The main Action takes place in total estimation sheet. Below is the image snippet which shows the various sections in the total estimation sheet. Let’s try to understand in numbered fashion what exactly the sheet means: - 1 - These columns are pulled from individual ILF, EIF, EI, EO and EQ sheets. 2 - This column (Unadjusted function points) is the total of ILF, EIF, EO, EQ and EI. 3 - GSC is the total of all GSC section from the GSC sheet. 4 - Based on GSC we get the total adjusted function points. Please refer the function point chapter in case you have doubts regarding what is EI, EO, EQ etc. We also input how much FP a programmer can complete in one day. This depends on what kind of programmer are you recruiting on the project. For instance if you have seniors in your project then you can enter probably 2 FP per day as seniors will be more productive. Page 63 of 215
5 - Here we distribute percentage wise man days according to the SDLC phases. But one important point to be noted is the total FP is nothing but the execution phase of the project. So we need to assign 100 % to execution and from that 100 % we take whatever percentage and distribute it to the other phases. 6 - In this column we define how many developers will be working on the project. 7 - Based on number of developers defined in 6 we get project schedule which is nothing but Total Man day divided by number of developers. Figure 1.26:- Total Estimation Template Note: - You can also watch the video explanation of the FunctionPoint Template from the CD. In this book we have shipped a complete book “How to prepare software Quotation”. This free E-book basically explains in detail manner other estimation technology widely used in projects. Testing Document The success of every project is test, test and test. All the professional projects in this CD have a test plan at the end. Below is the simple paste of a sample. This is basically an address application. The below action is when user updates the address. So basically we define steps with pass and failed conditions. Page 64 of 215
Update Address Steps for the test: o Start the Address book application o Select one of the addresses from the address data grid. Address details will be displ ayed on the textboxes above. o Change some information in all the three fields. o Press Update button Passed condition o System should save the changed information and display the newly entered data in the grid below. Failed condition o The system is not able to update the address data. Note :- All the professional projects in this book will all have the above documentation in project folder. That means every professional project will have use case document , test plan , estimation and a technical document. Chapter 2 OOPs Primer Why OOPs Object oriented programming enables programmers define not only the data, but also its associated behaviors/functions that can be applied to the data. It also enables programmers to create relationships between one object and another. For example, objects can inherit characteristics from other objects. To understand the importance of OOP we need to first understand the problem with procedural/structural programming practices. Procedural programming was suitable for small projects. But as the program grew in size, along with it grew the maintenance nightmare. Also, since the modules were tightly integrated changes in one part of the module inadvertently breaks the other part. Team development was not truly achievable. The next big problem with procedural programming was with respect to reusability. It was very difficult to write truly reusable code, with minimum maintenance. So why OOP? OOPs facilitates code reuse, team-development, eliminate redundant code, easy management of software complexity etc. To understand how OOP practices enable us to write better, maintainable software, we need to understand some of the fundamental aspects of OOP. Page 65 of 215
Fundamentals of OOPS To understand the fundamentals of OOPS, we need to be familiar with some of the terms programmers frequently use while developing object oriented software. Classes and Objects The class represents or defines the common characteristics/attributes of an object of a particular type. For e.g. you might want to define a class of “Person”. Every person will share some common characteristics/attributes like first name, last name, address etc.. So, a class serves as a blueprint for similar type of object. A class is made up of attributes and behavior. Attributes are defined in terms of member variables and behavior is expressed in terms of function. An object is an instance of a class. It is a representation of a real world thing. Object can have both attributes/data and behaviors. For e.g. You, me are instance of the “Person” class. We share some common attributes like we both have a first name, a last name and so on. We have some common behaviors like walking, talking etc. Abstraction Abstraction refers to the act of representing essential features without unnecessarily including the background details or information i.e. representing a complex problem in simple terms. Classes provides a mechanism to abstract the required attributes such as first name, last name in case of “Person” class and functions to operate on these attributes. Classes are also known as “Abstract Data Type or ADT”. Encapsulation(or Information Hiding) Encapsulation is a technique where data and its associated behaviors(function) are wrapped in a single unit (Class). The data is hidden from the outside word. The purpose is to reveal as little as possible about the inner workings of the class. The only way to access these data is through public interfaces provided by the functions. Inheritance Inheritance is a technique with which an object of one class acquires attributes and behaviors from an object of another class. This is one way to achieve reusability in OOP. Inheritance models “is-a” relationship. For e.g. a “car” is an automobile. In this case the “automobile” is called the base class and “car” is called as derived class or inherited class. This type of reuse is often called white-box reuse. This term refers to the fact that with inheritance, the parent class implementation is often visible to the subclasses. Below is how practically encapsulation and inheritance is implemented in C#. The “:” says that clsJobSeeker is the child of clsUser class and that’s how we define inheritance in C#. The private key shows how the complication is hidden from the external world. public class clsJobSeeker : clsUser { private string _JobSeekerName; Page 66 of 215
private string _SurName; private string _Address; private string _PhoneNumber; } Composition When reuse is achieved by composing another object, the technique is known as composition. Composition models “has-a” relationship. This approach requires that the objects have well-defined interfaces since the internals of the objects are unknown. Because objects are treated only as "black boxes," this type of reuse is often called black-box reuse Below is the code snippet which shows how composition is implemented in C#. Ine the below scenario clsUser is composed of clsMenus objects. So we create clsMenus object inside the clsUser class. public class clsUser { private clsMenus objMenus = new clsMenus(); } Polymorphism The ability of different objects to respond to the same message in different ways is called polymorphism. Polymorphism is also the ability of an object to take more than one forms, for e.g. an operation may exhibit different behavior in different instances. The behavior depends upon the types of data used in the operation. There are basically two types of polymorphism i.e. static and dynamic polymorphism. Method overloading is an example of static polymorphism whereas overriding would be an example of dynamic polymorphism. Below is how we implement polymorphism in project practically. There are two methods Login and Login with userId. So if the external consumer who is using this component calls only the login method it loads all the user and if they pass the userid then it will load only that user details. public void login() { } public void login(int intUserId) { } Page 67 of 215
Message An object in isolation is of no use. Its value comes from its interactions with other objects. This interaction takes place through messages. A message consists of three parts (i) A receiver object (ii) A method the receiver knows how to execute (iii) Parameters, if any. Cohesion Cohesion is a measure of how much an item, say for e.g. a class or method, makes sense. Objects with low cohesion are more likely to be changed. A method is highly cohesive if it does one thing and only one thing. High cohesion is desirable. Coupling Object coupling describes the degree of interrelationships among the objects that make up a system. The more any one object knows about any other object in the system, the tighter the coupling is between those objects. In other words, coupling is a measure of how two items, such as classes or methods, are interrelated. When one class depends on another class they are said to be coupled. When one class interacts with another class, but does not have any knowledge of the implementation details of the other class they are said to be loosely coupled. When one class relies on the implementation of another class, they are said to be tightly coupled. Always try for loose coupling among objects. Abstract classes and Interfaces Abstract Class Abstract are classes that cannot be instantiated, and are frequently either partially implemented, or not at all implemented. Abstract classes are useful when creating components because they allow you specify an invariant level of functionality in some methods, but leave the implementation of other methods until a specific implementation of that class is needed. When implementing an abstract class, you must implement each abstract method in that class, and each implemented method must receive the same number and type of arguments, and have the same return value, as the method specified in the abstract class. Classes can inherit from only one abstract class. Interface An interface is a reference type and it contains only abstract members. We cannot have any implementation code in the interface. The interface contains only declaration for its members. Interface’s members can be events, methods, properties and indexers. An interface is also known as a “contract”. The entire client which uses the interface must fulfill the contract by implementing the interface. A class can implement multiple interfaces. Page 68 of 215
while the customer is editing the customer data. EQ does not contain any derived data. The above customer data which is displayed does not contain any complex calculations. EQ Display Customer Edit Information Description Number of Number of FTR DET There are 5 DETs to be retrieved Customer Code, Customer Name, Credit Card number, Active, Customer Address. Only customer details and 5 2 customer address will be referenced. So according to the above ranking table Total function 3 Table :- EQ to display customer edit So now, let’s add the total function point got from above tables: Function Point Section Name Counted ILF Customer EO Credit Card check system 4 EIF credit card information 5 EI Customer (Add and 12 update) EQ display customer edit 3 information Total Unadjusted 31 Function Points Table :- Total of all function point So unadjusted function point comes to 31.Please note we have said this as Unadjusted function as we have not accounted other variance factor of project (Programmers leaving job, Language we will use, what architecture etc etc). In order to make it adjusted function point, we have to calculate and tabulate the GSC and come out with the VAF. GSC Value(0-5) Data communications 1 Distributed data processing 1 Performance 4 Heavily used configuration 0 Transaction rate 1 On-Line data entry 0 End-user efficiency 4 On-Line update 0 Page 56 of 215
Complex processing 0 Reusability 3 Installation ease 4 Operational ease 4 Multiple sites 0 Facilitate change 0 Total 22 Table :- GSC VAF = 0.65 + ((sum of all GSC factor)/100). = 0.65 + (22/100) = 0.87. This factor affects the whole FP like anything, be very particular with this factor. So now, Calculating the Adjusted FP = VAF * Total unadjusted FP = 0.87 * 31 = 26.97 = rounded to 27 FP. Now we know that the complete FP for the customer GUI is 27 FP. Now calculating the Efficiency factor, we say that we will complete 3 FP per day that is 9 working days. So, the whole customer GUI is of 9 working days (Note do not consider Saturday and Sundays in this). I know upper manager people will say make it 7 FP per day and over load the programmer. That’s why programmer works at night. Considering SDLC (System Development Life Cycle) Before reading this section please refers to different SDLC cycles in previous chapters. The main intention of introducing this section is because estimations are heavily affected by which software life cycle you follow. Because deliverables change according to SLDC model the project manager chooses for the project. Example for waterfall model we will have Requirement documents, Design documents, Source code and testing plans. But for Prototyping models in addition to the documents above we will also need to deliver the Rough prototype. For build and fix model we will not deliver any of the documents and the only document delivered will be source code. So according to SDLC model deliverables change and hence the quotation. We will divide the estimation across requirement, design, implementation (coding) and testing .In what way the estimation has to divide across all deliverables is all up to the project manager and his plans. Phase Percentage distribution effort Requirements 10% of total effort Design Phase 20% of total effort Coding Total effort given by unadjusted FP Testing 10% of total effort Table :- Phase wise distribution of effort The above sample is total 100 % distribution of effort across various phases. But as said it up to the project manager to change according to scenarios.Ok now from the above function point estimation the estimation is 9 days let’s try to divide it across all phases. Page 57 of 215
Phase Percentage distribution Distribution of man/ effort days across phases Requirements 10 % of total effort 0.9 days Design Phase 20 % of total effort 1.8 days Coding 100 % as given by the 9 Days unadjusted FP Testing 10 % of total effort 0.9 days Total 12.6 Days Table :- Phase wise effort distribution of man days The above table shows the division of project man/days across project. One of the important point to note is the estimation derived from unadjusted FP is 9 days and percentage of that man days is distributed across the total SDLC cycle. But for execution we have taken the 100 % of the man days derived from unadjusted FP. Any estimation technology (COCOMO, Use case points , FP , SMC) gives you total estimation of execution and not for other activities like documentation etc. So we have allocated total man days derived from unadjusted FP in coding and then percentage of it is distributed across other phases. Now let’s put down the final quotation. Just a small comment about test cases. Total number of Test Cases = (Function Point) raised to power of 1.2.This is as suggested from caper Jones. Number of Acceptance Test Cases = 1.2 * Function Points 20-25 % of total effort can be allocated to testing phase. Test cases are non -deterministic. That means if test passes it takes “X” amount of time and if it does not then to amend it take “Y” amount of time etc etc. Final Estimation One programmer will sit on the project with around 1000 $ salary / Month. So his 12.6 days salary comes to 290 dollars approx. The upper quotation format is in its simplest format. Every company has his quotation format accordingly. So no hard and fast rule of quotation template. But still if interested http://www.microsoft.com/mac/resources/ templates.aspx?pid=templates has good collection of decent templates. XYZ SOFTWARE COMPANY Page 58 of 215
To: TNC Limited, Western road 17, California. Quotation number: 90 Date: 1/1/2004 Customer ID: Z- 20090DATAENTRY Quantity Description Discount Taxable Total 1 Customer Project 0% 0% 466 dollars Quotation Valid for 100 days Goods delivery date with in 25 days of half payment Quotation Prepared by: - XYZ estimation department Approved by : - SPEG department XYZ. Table – Final bill CustomerSampleFP.xls is provided with the CD which has all estimation details which you can refer for practical approach. Note: - In this book we have shipped a complete book “How to prepare software Quotation”. This free E-book basically explains in detail manner other estimation technology widely used in projects. GSC Acceptance in Software industry GSC factors have been always a controversial topic. Most of the software companies do not use GSC, rather than they base line UAFP or construct there own table depending on company project history. ISO has also adopted function point as unit of measurement, but they also use UAFP rather than AFP. Let’s do a small experiment to view relationship between FP, AFP, GSC and VAF. In this experiment we will assume UAFP = 120 and then lot graph with GSC increment of five. So the formulae is VAF = 0.65 + (GS/100). Here’s the table with every five incremental values in formulae and plot. FP GSC 78 0 84 5 90 10 96 15 102 20 108 25 114 30 120 35 126 40 132 45 138 50 144 55 150 60 156 65 Page 59 of 215
162 70 Table :- GSC acceptance Figure 1.23:- FP versus VAF The following are the observation from the table and plot: - Graph is linear. It also captures that nature of complexity is linear. If the GSC value is zero then VAF is 0.65. So the graph starts from UAFP*0.65.GSC = 35 AFP = UAFP. So the VAF = 1. When GSC <> 35 then AFP > UAFP. That means complexity increases. Readers must be wondering why 0.65? There are fourteen GSC factor from zero to five. So the maximum value of VAF = 0.65 + (70/100) = 1.35. In order that VAF does not have any affect i.e. UAFP = FP VAF should be one. VAF will be one when GSC is 35 i.e. half of 70. So in order to complete value “1” value “0.65” is taken. Note value is 0.35 when GSC is 35 to complete the one factor “0.65” is required. But following is the main problem related to GSC. GSC is applied throughout FP even when some GSC does not apply to whole function points. Here’s the example to demonstrate GSC problem. Page 60 of 215
Let’s take 11th GSC factor “installation ease”. The project is of 100 UAFP and there is no consideration of installation previously by client so the 11th factor is zero. GSC with installation ease with ZERO GSC Value(0-5) Data communications 1 Distributed data processing 1 Performance 4 Heavily used configuration 0 Transaction rate 1 On-Line data entry 0 End-user efficiency 4 On-Line update 0 Complex processing 0 Reusability 3 Installation ease 0 Operational ease 4 Multiple sites 0 Facilitate change 0 Total 18 Table : GSC with installation ease zero VAF = 0.65 + (18/100) = 0.83. So the FP = 100 * 0.83 = 83 Function Points. But later the client demanded for full blown installation for the project with auto updating when new version is released. So we change out GSC table with installation ease to 5. GSC with installation eases “5” GSC with installation ease with FIVE GSC Value(0-5) Data communications 1 Distributed data processing 1 Performance 4 Heavily used configuration 0 Transaction rate 1 On-Line data entry 0 End-user efficiency 4 On-Line update 0 Complex processing 0 Reusability 3 Installation ease 5 Operational ease 4 Multiple sites 0 Facilitate change 0 Total 23 Page 61 of 215
Table :- GSC with Installation ease 5 So VAF = 0.65 + (23/100) = 0.88 so the FP = 100 * 0.88 = 88. The difference is of only 5 FP which from no way a proper effort estimate. To make an auto updation for a software versioning can no way be done in 5 function points , just think downloading new versi on, deleting the old version , updating any database structure changes etc etc. So that’s the reason GSC is not accepted in software industry. Best ways is baseline you’re UAFP and make your estimation on base of UAFP. Enhancement Function Points Major software project fail not because of programmer’s or project managers but due to moody and changing customers. In one of our huge projects we had good programmers, very enthusiastic. The project started of well but customer called ten times in a day to change something or other. Believe me programmers get pissed if the customer is changing his plans every fortnight. Well from this book point of view we have to evaluate this changes which can be addition or deletion of requirements. Function point group has come out with a methodology called as “Enhancement Function Points”. Down is the formulae Formulae of EFP (Enhanced Function Points) = (ADD + CHGA) * VAFA + (DELFP) * VAFB ADD: - This is new function points added. This value is achieved by counting all n ew EP (Elementary process) given in change request. CHGA: - Function points which are affected due to CR. This value is achieved by counting all DET, FTR, ILF, EI, EO and EQ which are affected. Do not count elements which are not affected. VAFA: - This is VAF factor which is because of CR. Example previously the application was desktop and now is changed to web so the GSC factor is affected. DELFP: - When CR is for removing some functionality this value is counted. It’s rare that customer removes functionalities (at least in India), but if they ever estimator has to take note of it by counting the deleted elementary process. VAFB: - Again removal affects Value added factor. Once we are through with calculating enhanced function points, it time to count total Function points of the application. Total Function points = [UFPB + ADD + CHGA] – [CHGB – DELFP] Page 62 of 215
UFPB: - Function points previously counted before enhancement. ADD: - Newly added functionality which leads to new function points after enhancements. CHGA: - Changed function points counted after enhancements. CHGB: - Changed function points before enhancements. DELFP: - Deleted function points. Enhancement function points is not covered from practical angle in this book and is left to the user’s as exercise. CR (Change request) is covered in more detail in Change request chapter. Function point template explanation In order to use FP in our project in easy fashion we will be using function point excel template to automate our estimation. In both Jobsite and chat application you can find the estimation sheet. When you open the sheet you can see the below section as shown in figure below. Total Estimation has the full consolidation of the estimation.ILF, EIF, EO, EQ, EI and GSC serves as an entry she et for all the necessary inputs. Figure 1.25 :- Different sections in FP template The main Action takes place in total estimation sheet. Below is the image snippet which shows the various sections in the total estimation sheet. Let’s try to understand in numbered fashion what exactly the sheet means: - 1 - These columns are pulled from individual ILF, EIF, EI, EO and EQ sheets. 2 - This column (Unadjusted function points) is the total of ILF, EIF, EO, EQ and EI. 3 - GSC is the total of all GSC section from the GSC sheet. 4 - Based on GSC we get the total adjusted function points. Please refer the function point chapter in case you have doubts regarding what is EI, EO, EQ etc. We also input how much FP a programmer can complete in one day. This depends on what kind of programmer are you recruiting on the project. For instance if you have seniors in your project then you can enter probably 2 FP per day as seniors will be more productive. Page 63 of 215
5 - Here we distribute percentage wise man days according to the SDLC phases. But one important point to be noted is the total FP is nothing but the execution phase of the project. So we need to assign 100 % to execution and from that 100 % we take whatever percentage and distribute it to the other phases. 6 - In this column we define how many developers will be working on the project. 7 - Based on number of developers defined in 6 we get project schedule which is nothing but Total Man day divided by number of developers. Figure 1.26:- Total Estimation Template Note: - You can also watch the video explanation of the FunctionPoint Template from the CD. In this book we have shipped a complete book “How to prepare software Quotation”. This free E-book basically explains in detail manner other estimation technology widely used in projects. Testing Document The success of every project is test, test and test. All the professional projects in this CD have a test plan at the end. Below is the simple paste of a sample. This is basically an address application. The below action is when user updates the address. So basically we define steps with pass and failed conditions. Page 64 of 215
Update Address Steps for the test: o Start the Address book application o Select one of the addresses from the address data grid. Address details will be displ ayed on the textboxes above. o Change some information in all the three fields. o Press Update button Passed condition o System should save the changed information and display the newly entered data in the grid below. Failed condition o The system is not able to update the address data. Note :- All the professional projects in this book will all have the above documentation in project folder. That means every professional project will have use case document , test plan , estimation and a technical document. Chapter 2 OOPs Primer Why OOPs Object oriented programming enables programmers define not only the data, but also its associated behaviors/functions that can be applied to the data. It also enables programmers to create relationships between one object and another. For example, objects can inherit characteristics from other objects. To understand the importance of OOP we need to first understand the problem with procedural/structural programming practices. Procedural programming was suitable for small projects. But as the program grew in size, along with it grew the maintenance nightmare. Also, since the modules were tightly integrated changes in one part of the module inadvertently breaks the other part. Team development was not truly achievable. The next big problem with procedural programming was with respect to reusability. It was very difficult to write truly reusable code, with minimum maintenance. So why OOP? OOPs facilitates code reuse, team-development, eliminate redundant code, easy management of software complexity etc. To understand how OOP practices enable us to write better, maintainable software, we need to understand some of the fundamental aspects of OOP. Page 65 of 215
Fundamentals of OOPS To understand the fundamentals of OOPS, we need to be familiar with some of the terms programmers frequently use while developing object oriented software. Classes and Objects The class represents or defines the common characteristics/attributes of an object of a particular type. For e.g. you might want to define a class of “Person”. Every person will share some common characteristics/attributes like first name, last name, address etc.. So, a class serves as a blueprint for similar type of object. A class is made up of attributes and behavior. Attributes are defined in terms of member variables and behavior is expressed in terms of function. An object is an instance of a class. It is a representation of a real world thing. Object can have both attributes/data and behaviors. For e.g. You, me are instance of the “Person” class. We share some common attributes like we both have a first name, a last name and so on. We have some common behaviors like walking, talking etc. Abstraction Abstraction refers to the act of representing essential features without unnecessarily including the background details or information i.e. representing a complex problem in simple terms. Classes provides a mechanism to abstract the required attributes such as first name, last name in case of “Person” class and functions to operate on these attributes. Classes are also known as “Abstract Data Type or ADT”. Encapsulation(or Information Hiding) Encapsulation is a technique where data and its associated behaviors(function) are wrapped in a single unit (Class). The data is hidden from the outside word. The purpose is to reveal as little as possible about the inner workings of the class. The only way to access these data is through public interfaces provided by the functions. Inheritance Inheritance is a technique with which an object of one class acquires attributes and behaviors from an object of another class. This is one way to achieve reusability in OOP. Inheritance models “is-a” relationship. For e.g. a “car” is an automobile. In this case the “automobile” is called the base class and “car” is called as derived class or inherited class. This type of reuse is often called white-box reuse. This term refers to the fact that with inheritance, the parent class implementation is often visible to the subclasses. Below is how practically encapsulation and inheritance is implemented in C#. The “:” says that clsJobSeeker is the child of clsUser class and that’s how we define inheritance in C#. The private key shows how the complication is hidden from the external world. public class clsJobSeeker : clsUser { private string _JobSeekerName; Page 66 of 215
private string _SurName; private string _Address; private string _PhoneNumber; } Composition When reuse is achieved by composing another object, the technique is known as composition. Composition models “has-a” relationship. This approach requires that the objects have well-defined interfaces since the internals of the objects are unknown. Because objects are treated only as "black boxes," this type of reuse is often called black-box reuse Below is the code snippet which shows how composition is implemented in C#. Ine the below scenario clsUser is composed of clsMenus objects. So we create clsMenus object inside the clsUser class. public class clsUser { private clsMenus objMenus = new clsMenus(); } Polymorphism The ability of different objects to respond to the same message in different ways is called polymorphism. Polymorphism is also the ability of an object to take more than one forms, for e.g. an operation may exhibit different behavior in different instances. The behavior depends upon the types of data used in the operation. There are basically two types of polymorphism i.e. static and dynamic polymorphism. Method overloading is an example of static polymorphism whereas overriding would be an example of dynamic polymorphism. Below is how we implement polymorphism in project practically. There are two methods Login and Login with userId. So if the external consumer who is using this component calls only the login method it loads all the user and if they pass the userid then it will load only that user details. public void login() { } public void login(int intUserId) { } Page 67 of 215
Message An object in isolation is of no use. Its value comes from its interactions with other objects. This interaction takes place through messages. A message consists of three parts (i) A receiver object (ii) A method the receiver knows how to execute (iii) Parameters, if any. Cohesion Cohesion is a measure of how much an item, say for e.g. a class or method, makes sense. Objects with low cohesion are more likely to be changed. A method is highly cohesive if it does one thing and only one thing. High cohesion is desirable. Coupling Object coupling describes the degree of interrelationships among the objects that make up a system. The more any one object knows about any other object in the system, the tighter the coupling is between those objects. In other words, coupling is a measure of how two items, such as classes or methods, are interrelated. When one class depends on another class they are said to be coupled. When one class interacts with another class, but does not have any knowledge of the implementation details of the other class they are said to be loosely coupled. When one class relies on the implementation of another class, they are said to be tightly coupled. Always try for loose coupling among objects. Abstract classes and Interfaces Abstract Class Abstract are classes that cannot be instantiated, and are frequently either partially implemented, or not at all implemented. Abstract classes are useful when creating components because they allow you specify an invariant level of functionality in some methods, but leave the implementation of other methods until a specific implementation of that class is needed. When implementing an abstract class, you must implement each abstract method in that class, and each implemented method must receive the same number and type of arguments, and have the same return value, as the method specified in the abstract class. Classes can inherit from only one abstract class. Interface An interface is a reference type and it contains only abstract members. We cannot have any implementation code in the interface. The interface contains only declaration for its members. Interface’s members can be events, methods, properties and indexers. An interface is also known as a “contract”. The entire client which uses the interface must fulfill the contract by implementing the interface. A class can implement multiple interfaces. Page 68 of 215
ليست هناك تعليقات:
إرسال تعليق