Introduction to Software
Engineering
Anand Kumar
Assistant Professor
Department of Computer Science and Engineering,
SEC, Sasaram
Software Project Management
The main goal of software project management is to enable a group of developers to work
effectively towards the successful completion of a project.
Software project management involves planning, organizing, and controlling the
development of software projects to ensure successful delivery within budget, time, and
quality constraints
Key Aspects of Software Project Management
● Planning: Defining project goals, scope, requirements, and deliverables.
● Scheduling: Creating a timeline and assigning tasks with deadlines.
● Resource Allocation: Assigning team members and other resources to tasks.
● Risk Management: Identifying, assessing, and mitigating potential risks.
● Budget Management: Tracking and controlling project costs.
● Quality Assurance: Ensuring the software meets the required standards.
● Communication: Maintaining clear and consistent communication with stakeholders.
● Change Management: Handling changes to the project scope, requirements, or schedule.
● Monitoring and Control: Tracking progress, identifying issues, and taking corrective actions.
● Software Development Life Cycle (SDLC) Management: Understanding and managing the
different phases of software development (e.g., requirements, design, implementation, testing,
deployment).
● Project Management Methodologies: Utilizing different methodologies like Agile or Waterfall
to manage the project.
● Tools and Techniques: Utilizing project management software and techniques to facilitate
project management. Stakeholder Management: Managing expectations and relationships
with stakeholders.
SOFTWARE PROJECT MANAGEMENT COMPLEXITIES
Invisibility:Invisibility of software makes it difficult to assess the progress of a
project and is a major cause for the complexity of managing a software project.
Changeability: Frequent changes to the requirements and the invisibility of
software are possibly the two major factors making software project management
a complex task.
Complexity: Inherent complexity of the functioning of a software product in
terms of the basic parts making up the software, many types of risks are
associated with its development. This makes managing these projects much more
difficult as compared to many other kinds of projects.
Uniqueness: Every software project is usually associated with many unique
features or situations. This makes every project much different from the others. A
software project manager has to confront many unanticipated issues in almost
every project that he manages.
SOFTWARE PROJECT MANAGEMENT COMPLEXITIES
Exactness of the solution:the parameters of a function call in a program are
required to be in complete conformity with the function definition. This
requirement not only makes it difficult to get a software product up and working,
but also makes reusing parts of one software product in another difficult. This
requirement of exact conformity of the parameters of a function introduces
additional risks and contributes to the complexity of managing software projects.
Eg: Mechanical components such as nuts and bolts typically work satisfactorily as
long as they are within a tolerance of 1 per cent or so of their specified sizes.
Team-oriented and intellect-intensive work: In a software development project, the
life cycle activities not only highly intellect-intensive, but each member has to
typically interact, review, and interface with several other members, constituting
another dimension of complexity of software projects.
RESPONSIBILITIES OF A SOFTWARE PROJECT MANAGER
• Previous experience in managing similar projects.Project planning:
Project planning involves estimating several characteristics of a project and
then planning the project activities based on these estimates made.
Project monitoring and control: The focus of project monitoring and control
activities is to ensure that the software development proceeds as per plan.
Three Skills that are most critical to successful project management are the
following:
• Knowledge of project management techniques.
• Decision taking capabilities.
• Previous experience in managing similar projects.
PROJECT PLANNING
● Estimation:
○ Size is the most fundamental parameter based on which all other estimations
and project plans are made.
■ Cost:
■ Duration:
■ Effort:
● Scheduling:
● Staffing:
● Risk management
● Miscellaneous plans: quality assurance plan,configuration management plan, etc.
Once project planning is complete, project managers documents their plans in a
software project management plan(SPMP) document.
Organisation of the software project management plan (SPMP) document
● Introduction
● Project estimates
○ Historical Data Used
○ Estimation Techniques Used
○ Effort, Resource, Cost, and Project Duration Estimate
● Schedule
○ Work Breakdown Structure
○ Task Network Representation
○ Gantt Chart Representation
○ PERT Chart Representation
● Project resources
○ People
○ Hardware and Software
○ Special Resources
Organisation of the software project management plan (SPMP) document Cont…
● Staff organisation
○ Team Structure
○ Management Reporting
● Risk management plan
○ Risk Analysis
○ Risk Identification
○ Risk Estimation
○ Risk Abatement Procedures
● Project tracking and control plan
○ Metrics to be tracked
○ Tracking plan
○ Control plan
Organisation of the software project management plan (SPMP) document Cont…
Miscellaneous plans
● Process Tailoring
● Quality Assurance Plan
● Configuration Management Plan
● Validation and Verification
● System Testing Plan
● Delivery, Installation, and Maintenance Plan
METRICS FOR PROJECT SIZE ESTIMATION
Lines of Code (LOC)
LOC is a measure of coding activity alone: The implicit assumption made by the LOC metric is
that the overall product development effort is solely determined from the coding effort alone is
flawed(Not Correct).
LOC count depends on the choice of specific instructions: Even for the same programming
problem, different programmers might come up with programs having very different LOC counts.
This situation does not improve, even if language tokens are counted instead of lines of code.
LOC measure correlates poorly with the quality and efficiency of the code: Larger code size does
not necessarily imply better quality of code or higher efficiency.
LOC metric penalises use of higher-level programming languages and code reuse:
LOC metric measures the lexical complexity of a program and does not address the more
important issues of logical and structural complexities:
It is very difficult to accurately estimate LOC of the final program from problem specification:
METRICS FOR PROJECT SIZE ESTIMATION
Function Point (FP) Metric
Function points are one of the most commonly used measures of software size and complexity.
It is a unit of measurement used to quantify the amount of business functionality being delivered by a
software application and allow software engineers to better measure the size of a project, identify areas
in need of optimization, and analyze development performance benchmarks over time.
the function point metric is based on the idea that a software product supporting many features would
certainly be of larger size than a product with less number of features.
Steps to compute function point
When function is invoked, read some input data and transform it to corresponding output data.
Example the issue book feature of a library automation software takes the name of the book as
input and displays its location and the number of copies available.
• Beside using the number of the input and output data values function point metric computes
the size of a software product
Function point (FP) metric computation
Step 1: Compute the unadjusted function point (UFP) using a heuristic expression.
Step 2: Refine UFP to reflect the actual complexities of the different parameters used in UFP
computation.
Step 3: Compute FP by further refining UFP to account for the specific
characteristics of the project that can influence the entire development effort.
Step 1: UFP computation
The unadjusted function points (UFP) is computed as the weighted sum of
five characteristics of a product as shown in the following expression. The
weights associated with the five characteristics were determined
empirically by Albrecht through data gathered from many projects.
UFP=(number of input)*4+(number of outputs)*5+(number of enquiries)*4+(number of files)*10+ (number of interfaces)*10
1) number of inputs: In this is data item input by the user is counted. Data import should be distinguished from the inquiries.
Individual data items input by the user are not considered in the calculation of the number of input, but a group of related inputs
are considered as single input. it should be noted that data inputs are considered different from user inquiries.
Input
Payroll System = Name These are enquiries = User commands
considered as
Age
single input as Print Account Balance
Sex they are related to Issue books
Address single employee
Mobile No.
UFP computation
2) Number of outputs: The outputs considered include reports printed, screen outputs, error
messages produced, etc. While computing the number of outputs, the individual data items within
a report are not considered; but a set of related data items is counted as just a single output.
UFP computation
3) Number of inquiries: An inquiry is a user command (without any data input) and only requires
some actions to be performed by the system. Thus, the total number of inquiries is essentially the
number of distinct interactive queries (without data input) which can be made by the users.
Examples of such inquiries are print account balance, print all student grades, display rank
holders’ names, etc.
4) Number of files: The files referred to here are logical files. A logical file represents a group of
logically related data. Logical files include data structures as well as physical files.
5) Number of interfaces: Here the interfaces denote the different mechanisms that are used
to exchange information with other systems. Examples of such interfaces are data files on
tapes, disks, communication links with other systems, etc.
Step 2: Refine parameters
UFP computed at the end of step 1 is a gross indicator of the problem size. This UFP needs
to be refined. This is possible, since each parameter (input, output, etc.) has been implicitly
assumed to be of average complexity. Some input values may be extremely complex, some
very simple, etc. In order to take this issue into account, UFP is refined by taking into
account the complexities of the parameters of UFP computation. The complexity of each
parameter is graded into three broad categories—simple, average, or complex. The weights
for the different parameters are determined based on the numerical values shown in Table
below. Based on these weights of the parameters, the parameter values in the UFP are
refined. For example, rather than each input being computed as four FPs, very simple
inputs are computed as three FPs and very complex inputs as six FPs.
Step 2: Refine parameters
Refinement of Function point metrics
Type Simple Average Complex
Input 3 4 6
Output 4 5 7
Enquiry 3 4 6
No. of Files 7 10 15
No. of
5 7 10
Interfaces
Step 3: Refine UFP based on complexity of the overall
project
Compute TCF(Technical Complexity Factor)
TCF 0.65 +0.01*(DI)
DI= Degree of influence
FP = UFP * TCF
Step 3: Refine UFP based on complexity of the overall
project
We Calculate Degree of Influence, bases on the different 14 parameter as below. 0 means no
influence and 6 means high influence. Different parameter that may influence the development process.
Requirement for data communication
Extent of distributed processing
Performance requirements
Expected operational environment
Extent of online data entries
Extent of multi-screen or multi-operation online data input
Extent of online updating of master files
Extent of complex inputs, outputs, online queries and files
Extent of complex data processing
Extent that currently developed code can be designed for reuse
Extent of conversion and installation included in the design
Extent of multiple installations in an organisation and variety of
customer organisations
Extent of change and focus on ease of use
Example to compute Function Point Metric
Determine the function point measure of the size of the following supermarket
software. A supermarket needs to develop the following software to encourage
regular customers. For this, the customer needs to supply his/her residence
address, telephone number, and the driving license number. Ea ch customer who
registers for this scheme is assigned a unique customer number (CN) by the
computer. Based on the generated CN, a clerk manually prepares a customer
identity card after getting the market manager’s signature on it. A customer can
present his customer identity card to the check out staff when he makes any
purchase. In this case, the value of his purchase is credited against his CN. At the
end of each year, the supermarket intends to award surprise gifts to 10 customers
who make the highest total purchase over the year. Also, it intends to award a 22
caret gold coin to every customer whose purchase exceeded Rs. 10,000. The entries
against the CN are reset on the last day of every year after the prize winners’ lists
are generated. Assume that various project characteristics determining the
complexity of software development to be average.
Example to compute Function Point Metric
Step 1: From an examination of the problem description, we find that there
are two inputs, three outputs, two files, and no interfaces. Two files would
be required, one for storing the customer details and another for storing the
daily purchase records. Now, using equation, we get:
UFP = 2 × 4 + 3 × 5 + 1 × 4 + 10 × 2 + 0 × 10 = 47
Example to compute Function Point Metric
Step 2: All the parameters are of moderate complexity, except the * output
parameter of Customer registration, in which the only output is the CN
value. Consequently, the complexity of the output parameter of the
customer registration function can be categorized as simple. By consulting
Table Above, we find that the value for simple output is given to be 4. The
UFP can be refined as follows:
UFP = 3 × 4 + 2 × 5 + 1 × 4 + 10 × 2 + 0 × 10 = 46
Therefore, the UFP will be 46.
Example to compute Function Point Metric
Step 3: Since the complexity adjustment factors have average values,
therefore the total degrees of influence would be:
DI = 14 × 4 = 56
TCF = 0.65 + 0.01 + 56 = 1.21
Therefore, the adjusted FP=46*1.21=55.66
Thank you