Wednesday, 28 August 2019
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 * VAFAdvantages:
· 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).
· 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.
· 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 )
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.
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.
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.
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).
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
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
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:
Subscribe to:
Posts (Atom)