Pages

Thursday, 1 August 2019

Function Point

             A Function Point (FP) is a unit of measurement to express the amount of business functionality, an information system (as a product) provides to a user. FPs measure software size. They are widely accepted as an industry standard for functional sizing.

Internal Logical Files

        Internal Logical File (ILF) is a user identifiable group of logically related data or control information that resides entirely within the application boundary. The primary intent of an ILF is to hold data maintained through one or more elementary processes of the application being counted. An ILF has the inherent meaning that it is internally maintained, it has some logical structure and it is stored in a file. (Refer Figure 1)

External Interface Files

        External Interface File (EIF) is a user identifiable group of logically related data or control information that is used by the application for reference purposes only. The data resides entirely outside the application boundary and is maintained in an ILF by another application. An EIF has the inherent meaning that it is externally maintained, an interface has to be developed to get the data from the file. (Refer Figure 1)

External Inputs

External Input (EI) is a transaction function in which Data goes “into” the application from outside the boundary to inside. This data is coming external to the application.
  • Data may come from a data input screen or another application.
  • An EI is how an application gets information.
  • Data can be either control information or business information.
  • Data may be used to maintain one or more Internal Logical Files.
  • If the data is control information, it does not have to update an Internal Logical File. (Refer Figure 1)

External Outputs

    External Output (EO) is a transaction function in which data comes “out” of the system. Additionally, an EO may update an ILF. The data creates reports or output files sent to other applications.


External Inquiries

    External Inquiry (EQ) is a transaction function with both input and output components that result in data retrieval.


FP Counting Process involves the following steps −

·  Step 1 − Determine the type of count.
·  Step 2 − Determine the boundary of the count.
·  Step 3 − Identify each Elementary Process (EP) required by the user.
·  Step 4 − Determine the unique FP.
·  Step 5 − Measure data functions using EI, EO & EQ.
·  Step 6 − Measure transactional functions using ILF &EIF.
· Step 7−Calculate functional size (unadjusted function point count).
·  Step 8 − Determine Value Adjustment Factor (VAF).
·  Step 9 − Calculate Adjusted function point count.

    Use the ’14 general characteristics (GSC)  ’ of a system to find the degree of influence of each of them.

Compute Value Adjustment Factor(VAF): Use the following formula to calculate VAF

     VAF = (65 + ∑GSC ) / 100

Use the following formula to calculate Adjusted Function Point Count or Function Point Count 

                         AFP = UFP * VAF


Advantages:
·  It can be easily used in the early stages of project planning.
·  It is independent of the programming language.
·  It can be used to compare different projects even if they use different technologies(database, language etc).

Disadvantages:
·  It is not good for real-time systems and embedded systems.
·  Many cost estimation models like COCOMO uses LOC and hence   FPC must be converted to LOC.

For Example: Compute the function point value for grade calculation of students. Assume that it is an average complexity size project the information domain values are as follows 

Number of inputs=13
Number of outputs=4
Number of inquiries=2
Number of External Interfaces (EIF)=5
Number of Internal logical files (ILF)=2

UFP = 13 *( avg value ) + 4 *( avg value ) + 2 *( avg value ) + 5 *( avg value ) + 2 *( avg value ) 

VAF = (65 + ∑GSC ) / 100

AFP = UFP * VAF


 








Software process and project metrics

Software process and project metrics

Software process and project metrics are quantitative measures that enable software engineers to gain insight into the efficiency of the software process and the projects conducted using the process framework. In software project management, we are primarily concerned with productivity and quality metrics. The four reasons for measuring software processes, products, and resources (to characterize, to evaluate, to predict, and to improve).
Measures, Metrics, and Indicators

Measure -  provides a quantitative indication of the size of some product or process attribute
Measurement -  is the act of obtaining a measure
Metric -  is a quantitative measure of the degree to which a system, component, or process possesses a given attribute.



Process and Project Indicators
Metrics should be collected so that process and product indicators can be ascertained
Process indicators enable software project managers to: assess project status, track potential risks, detect problem area early, adjust workflow or tasks, and evaluate team ability to control product quality.

Process Metrics
Private process metrics (e.g. defect rates by individual or module) are known only to the individual or team concerned.
Public process metrics enable organizations to make strategic changes to improve the software process.
Metrics should not be used to evaluate the performance of individuals.
Statistical software process improvement helps and organization to discover where they are strong and where are weak.

Project Metrics
Software project metrics are used by the software team to adapt project workflow and technical activities.
Project metrics are used to avoid development schedule delays, to mitigate potential risks, and to assess product quality on an on-going basis.
Every project should measure its inputs (resources), outputs (deliverables), and results (effectiveness of deliverables).


Project Organisation

 Project Organisation
A project organisation is one , in which a project structure is created as a separate unit or division within a permanent functional structure, drawing specialists and workers from various functional departments who work under the overall leadership , control and co-ordination of a project manager or complete projects of a technical and costly nature.

The project team functions under the overall control and leadership of the project manager. During the continuance of project, functional manager renounce their authority over subordinate in favour of the project manager.

The project organisation is further mainly divided in 3 ways. They are:
1) Centralized controlled team organisation
2) Decentralized control team organisation
3) Mixed control team organisation

1. Centralized control team organisation:

A centralized organisation is one where core important decisions are taken by those at important decisions are taken by those at a higher level of authority. All important decisions are routed through this channel and are taken by those with broader perspective and have gained knowledge and experience over the years. The decision is further communicated to the lower level employees who are expected to follow the orders.
This does not mean that there is just one person making all decisions .People at different level are authorised but, unlike decentralised organisation, there is less team based decision making and more of individual decision making .

               
                       

Decentralised control team organisation:

Decentralisation is defined as a systematic delegation of authority at all levels of management and in all of the organisation. In this system , the highest level of management are in charge of making major companywide decision framework for the rest of the firm.
Decentralised focuses on learning dynamics and relies on a bottom-up philosophy. The decision making style is democratic and detail oriented, since input from every level is checked are re-checked each time a decision is made.


                                         
Mixed control team organisation:

Mixed model or matrix organizational structure , has multiple line of authority with some employees reporting to at least two managers. There are functional managers who oversee departments such as engineering and marketing and there are project managers who oversee employees who work on specific project.
Here by, the project organisation structure and its further categories are explained in detailed with respective figures. These ways help in project organisation.

        


Software project management focuses on the  4 P’s: Project, Product, Process and People

1.Project:
       We conduct planned and controlled software projects for one primary reason it is the only known way to manage complexity.

      A software project manager and the software engineers who build the product must avoid a set of common warning signs, understand the critical success factors that lead to good project management, and develop a common sense approach for planning, monitoring and controlling the project.

2.Product
      Before a project can be planned, product objectives and scope should be established, alternative solutions should be considered and technical and management constraints should be identified

      Without this information, it is impossible to define reasonable estimates of the cost, an effective assessment of risk, a realistic breakdown of project tasks, or a manageable project schedule.           

   Objectives identify the overall goals for the product without considering how these goals will be achieved.

    Scope identifies the primary data, functions and behaviours that characterize the product.

  Once the product objectives and scope are understood, alternative solutions are considered. From the available various alternatives, managers and practitioners select a "best" approach.

3. Process 
        A software process provides the framework from which a comprehensive plan for software development can be established.

      A small number of frame-work activities are applicable to all software projects, regardless of their size or complexity.

         A number of different tasks, milestones, work products and quality assurance points enable the framework activities to be adapted to the characteristics of the software project and the requirements of the project team.

         Finally, umbrella activities such as software quality assurance, software configuration management, and measurement overlay the process model 

4.People

        People factor is very much important in the process of software development.


     There are following areas for software people like, recruiting, selection, performance management, training, compensation, career development, organization and work design, and team/culture development.
        
           Organizations achieve high levels of maturity in the people management area.

Critical Path Method (CPM)

Critical Path Method (CPM) is a method used in project planning, generally for project scheduling for the on-time completion of the project. It actually helps in the determination of the earliest time by which the whole project can be completed. There are two main concepts in this method namely critical task and critical path.

Critical task is the task/activity which can’t be delayed otherwise the completion of the whole project will be delayed. It must be completed on-time before starting the other dependent tasks.

Critical path is a sequence of critical tasks/activities and is the largest path in the project network. It gives us the minimum time which is required to complete the whole project. The activities in the critical path are known as critical activities and if these activities are delayed then the completion of the whole project is also delayed.

Major steps of the Critical Path Method:
1.Identifying the activities
2.Construct the project network
3.Perform time estimation using forward and backward pass
4.Identify the critical path
The table given below contains the activity label, its respective duration (in weeks) and its precedents. We will use critical path method to find the the critical path and activities of this project.

ACTIVITY
PRECEDENTS
DURATION
A
6
B
4
C
A
3
D
B
4
E
B
3
F
10
G
E, F
3
H
C, D
2

Rules for designing the Activity-on-Node network diagram:
· A project network should have only one start node
· A project network should have only one end node
· A node has a duration
· Links normally have no duration
· “Precedents” are the immediate preceding activities
· Time moves from left to right in the project network
· A network should not contain loops
· A network should not contain dangles

Node Representation :
Forward path :
Backward path:

Critical path: