Unit 2

Introduction to UML
• UML is a standard language for specifying,
visualizing, constructing, and documenting the
artifacts of software systems.
• UML was created by the Object Management
Group (OMG)
• UML stands for Unified Modeling Language.
• UML is different from the other common
programming languages such as C++, Java, COBOL,
etc.
• UML is a pictorial language used to make software
blueprints.
• UML can be described as a general purpose visual
modeling language to visualize, specify, construct,
and document software system.
 A Conceptual Model of UML
• A conceptual model can be defined as a model
which is made of concepts and their relationships.
• A conceptual model is the first step before
drawing a UML diagram.
• It helps to understand the entities in the real
world and how they interact with each other.
• The conceptual model of UML can learning by
following three major elements −
• UML building blocks.
• Rules to connect the building blocks.
• Common mechanisms of UML.
 The building blocks of UML
• The building blocks of UML can be defined as
1. Things
2. Relationships
3. Diagrams
1. Things: Anything that is a real world
entity or object is termed as things. It
can be divided into several different
categories
I. Structural
II. Behavioral
III. Grouping
IV. Annotational
 I. Structural Things
• Structural things: define the static part of the
model.
• They represent the physical and conceptual
elements. Following are the brief descriptions
of the structural things.
• Class Diagram
• Objects diagrams
• Deployment diagrams
• Package diagrams
• Component diagram
 Class Diagram.
• What is Class?
• A Class is a blueprint that is used to create Object. The Class
defines what object can do.
• What is Class Diagram?
• Class Diagram gives the static view of an application.
• A class diagram describes the types of objects in the system
and the different types of relationships that exist among
them.
• This modeling method can run with almost all
Object-Oriented Methods.
• This Diagram includes the class name, attributes, and
operation in separate designated compartments.
• Class Diagram helps construct the code for the software
application development.
 Essential elements of A UML class
diagram
• Class Name
• Attributes
• Operations

AddData()
 Relationships
• There are mainly three kinds of relationships in
UML:
• Dependencies
• Generalizations
• Associations
 Dependiencies
• Dependency indicates that one class depends
on another.
• In the following example, Student has a
dependency on College
 Generalization:
• A generalization helps to connect a subclass to
its superclass.
• A sub-class is inherited from its superclass.
Class diagram allows inheriting from multiple
superclasses.
 Association
• This kind of relationship represents static
relationships between classes A and B.
• For example; an student studies in college.
Aggregation vs. Composition
Example of Class Diagram
 Best practices of Designing of the
Class Diagram
• The name given to the class diagram must be
meaningful. Moreover, It should describe the real
aspect of the system.
• The relationship between each element needs to be
identified in advance.
• The responsibility for every class needs to be
identified.
• For every class, minimum number of properties should
be specified. Therefore, unwanted properties can
easily make the diagram complicated.
• At the end of the drawing, it must be understandable
for the software development team.
• Lastly, before creating the final version, the diagram
needs to be drawn on plain paper. Moreover, It should
be reworked until it is ready for final submission.
 Case Study For Library Management System
• First the management of the library approached this ABC Software Ltd. for their
request for the new automated system. What they stated in their request was that
they needed a system for their library that could automate its various functions. And
provide faster response.
• From this request statement, it is very difficult for the analyst to know what exactly
the customer wants. So in order to get information about the system, the analyst
visits the library site and meets the staff of the library. Library staff is going to be the
end user of the system. Analyst asks various questions from the staff so that the
exact requirements for the system become clear. From this activity, the analyst is
able to identify the following requirements for the new system:
• Function for issue of books
• Function for return of books that can also calculate the fine if the book is returned
after the due date
• Function for performing different queries
• Report generation functions
• Function for maintaining account s
• Maintaining the details for members, books, and suppliers in some structured way.
• Now that the requirements are known, the analyst proposes solution system.
• Solution: The desired system can be implemented with Oracle RDBMS in the back
end with Visual Basic as the front end. It will have modules for handling issue and
return functions, generating reports, performing checks, and maintaining accounts. It
will also store the data relating to books, members, and suppliers in a structures way.
In our case, the data will be maintained in a relational way.
 Object Diagram
• Object diagrams are derived from class
diagrams so object diagrams are dependent
upon class diagrams.
• Object diagrams represent an instance of a
class diagram.
 Purpose Object Diagrams?
• An object diagram is a diagram that shows
a complete or partial view of the structure of
a modeled system at a specific time.”
 Class Diagram vs. Object Diagram
• In UML, object diagrams provide a snapshot of
the instances in a system and the relationships
between the instances.
• In a class diagram, you can explore the
behavior of a system.
• Object diagrams show specific instances of
those classifiers and the links between those
instances at a point in time.
 How to draw an Object Diagram?
• Draw all the necessary class diagrams for the
system.
• Identify the crucial points in time where a
system snapshot is needed.
• Identify the objects which cover crucial
functionality of the system.
• Identify the relationship between objects
drawn.
 Uses of an Object Diagram
• Model the static design(similar to class diagrams )
or structure of a system using prototypical
instances and real data.
• During the analysis phase of a project, you might
create a class diagram to describe the structure of
a system and then create a set of object diagrams
as test cases to verify the accuracy and
completeness of the class diagram.
• Helps us to understand the functionalities that the
system should deliver to the users.
• Understand relationships between objects.
• Verify the class diagrams for completeness and
accuracy by using Object Diagrams as specific test
cases.
 Deployment Diagram
• To show a physical view of the system then we
use deployment diagram.
• Deployment diagrams are used to visualize the
topology of the physical components of a
system, where the software components are
deployed.
 Purpose of Deployment Diagrams

• They show the structure of the run-time

system.
• They capture the hardware that will be used
to implement the system and the links
between different items of hardware.
• They model physical hardware elements and
the communication paths between them.
 Deployment diagrams commonly
contain:
• Nodes.
• 3-D box represents a node, either software or
hardware
• HW node can be signified with
<<stereotype>>
• Connections between nodes are represented
with a line, with optional <<stereotype>>
• Nodes can reside within a node
Steps for Modeling an Embedded
System
 Component Diagram
• Component diagrams are used to model the
physical aspects of a system.
• Physical aspects are the elements such as
executables, libraries, files, documents, etc.
which reside in a node.
 Purpose of Component Diagrams

• It does not describe the functionality of the

system but it describes the components used
to make those functionalities.
• Component diagrams are used to visualize the
physical components in a system. These
components are libraries, packages, files, etc.
Basic Concepts of Component Diagram
• A rectangle with the component's name
• A rectangle with the component icon
• A rectangle with the stereotype text and/or
icon
 Interfaces in component diagrams
• A full circle represents an interface created or
provided by the component.
• A semi-circle represents a required interface,
like a person's input.
Patient Database

utility
 Package Diagram
• Package diagram, a kind of structural diagram,
shows the arrangement and organization of
model elements in middle to large scale
project.
 Purpose of Package Diagrams
• Package Diagram can be used to simplify
complex class diagrams, it can group classes
into packages.
• A package is a collection of logically related
UML elements.
• Packages are depicted as file folders and can
be used on any of the UML diagrams.
 Behavioral Things
• UML Behavioral Diagrams depict the elements of a
system that are dependent on time and that convey
the dynamic concepts of the system and how they
relate to each other.
• The elements in these diagrams are like the verbs in a
natural language and the relationships that connect
them typically convey the passage of time.
• For example, a behavioral diagram of a vehicle
reservation system might contain elements such as
Make a Reservation, Rent a Car, and Provide Credit
Card Details.
 Behavioral Things includes.
• use case diagrams
• Sequence diagram
• state–chart diagrams
• activity diagrams.
 Use case diagrams
• Use case diagrams are usually referred to as behavior
diagrams.
• Use cases specify the expected behaviour (what), and not
the exact method of making it happen (how).
• It is an effective technique for communicating system
behavior in the user's terms by specifying all externally
visible system behavior.
• It only summarizes some of the relationships between use
cases, actors, and systems.
• It does not show the order in which steps are performed to
achieve the goals of each use case.
• Use cases represent only functional requirements of a
system
• Describe the manner in which outside things (Actors)
interact at the system boundary
• Describe the response of the system
 Actor & Usecase
• An actor represents the roles that the users of the use cases
play.
• An actor may be a person (e.g. student, customer), a device
(e.g. workstation), or another system (e.g. bank, institution).
• Use case represent an outside view of the manner the
elements in a system behave and how they can be used in the
context.
 Purpose of Use Case Diagram
• Use case diagrams are typically develop in early
stage of development and people often apply use
case modeling for the following purposes:
• Specify the context of a system
• Capture the requirements of a system
• Validate a systems architecture
• Drive implementation and generate test cases
• Developed by analysts together with domain
experts
Use Case Diagram - Vehicle Sales
Systems
Hotel Management
 Sequence diagram
• A sequence diagram simply depicts interaction
between objects in a sequential order i.e. the
order in which these interactions take place.
• These diagrams are widely used by
businessmen and software developers to
document and understand requirements for
new and existing systems.
 Sequence Diagram Notations –
• Actors – represents a type of role where it
interacts with the system and its objects.

• Lifelines – A lifeline is a named element which

depicts an individual participant in a
sequence diagram.
• format – Instance Name : Class Name
 Activations

• A thin rectangle on a lifeline) represents the

period during which an element is performing
an operation.
• The top and the bottom of the of the
rectangle are aligned with the initiation and
the completion time respectively
 Difference between a lifeline and an
actor –
• A lifeline always portrays an object internal to
the system whereas actors are used to depict
objects external to the system.
• Messages – Communication between objects
is depicted using messages.
• The messages appear in a sequential order on
the lifeline.
• We represent messages using arrows.
• We use a solid arrow head to represent a
synchronous message.
• We use a dotted arrow head to represent a
Asynchronous message.
 Delete Message –
• When an object is deallocated memory or is
destroyed within the system we use the
Delete Message symbol.
• represented by an arrow terminating with a x.
 Self Message –
• Certain scenarios might arise where the
object needs to send a message to itself.
represented with a U shaped arrow.
 Reply Message –
• message being sent from the receiver to the
sender. The interaction moves forward only
when a reply message is sent by the receiver.
 Found Message –
• A Found message is used to represent a
scenario where an unknown source sends the
message.
• For example: Consider the scenario of a
hardware failure.
 Lost Message –
• A Lost message is used to represent a
scenario where the recipient is not known to
the system
• For example: Consider a scenario where a
warning is generated.
 Guards –
• They are used when we need to restrict the
flow of messages on the pretext of a condition
being met.
• For example: In order to be able to withdraw
cash, having a balance greater than zero is a
condition that must be met as shown below.
 What is a state diagram
or State Machine in UML
• A state machine is any device that stores the
status of an object at a given time and can
change status or cause other actions based on
the input it receives. States refer to the
different combinations of information that an
object can hold, not how the object behaves.
 Basic components of a statechart
diagram –
• Initial state – We use a black filled circle represent
the initial state of a System or a class.
• Transition – change of control from one state to
another.

• State –rounded rectangle represent a state. A

state represents the conditions or circumstances
of an object of a class at an instant of time.
• Fork – use the fork notation to represent a
state splitting into two or more concurrent
states.
• Join-- We use the join notation when two or
more states concurrently converge into one on
the occurrence of an event or events.
• Composite state – We represent a state with
internal activities using a composite state.

• Final state – We use a filled circle within a

circle notation to represent the final state in a
state machine diagram.
 Activity Diagram
• Activity diagram shows flow of
control or object flow with emphasis on the
sequence and conditions of the flow.
 Activity Diagram Notations –
• nitial State – The starting state before an
activity takes place is depicted using the initial
state.
• Action or Activity State – An activity
represents execution of an action on objects.
• Action Flow or Control flows – Action flows or
Control flows are also referred to as paths and
edges.
• Decision node and Branching – When we
need to make a decision before
deciding the flow of control,
we use the decision node.
• Guards – A Guard refers to a statement
written next to a decision node on an arrow
sometimes within square brackets.

• Fork – Fork nodes are used to support

concurrent activities.
• Join – Join nodes are used to support
concurrent activities converging into one. For
join notations we have two or more incoming
edges and one outgoing edge.
State chart
Activity diagram
 Software Configuration Management
Process (SCM)
• Software Configuration Management(SCM) is the discipline
for systematically controlling the changes in software and
supporting documents during the software development
life cycle.
• When a software is build, there is always scope for
improvement and those improvements brings changes in
picture.
• Changes may be required to modify or update any existing
solution or to create a new solution for a problem.
• Requirements keeps on changing on daily basis and so we
need to keep on upgrading our systems based on the
current requirements and needs to meet desired outputs.
• Changes should be analyzed before they are made to the
existing system and controlled in a manner that will improve
quality and reduce error.
 major components or tasks in SCM:
• Configuration Identification
• Baselines
• Change Control
• Configuration Status Accounting
• Configuration Audits and Reviews
 Configuration Identification:
• when a change is done, it should be clear to what
changes has been applied.
• Identification of configuration Items like source
code modules, test case, and requirements
specification.
• Example:
• Instead of naming a File login.php its should be
named login_v1.2.php where v1.2 stands for the
version number of the file
• Instead of naming folder "Code" it should be
named "Code_D" where D represents code should
be backed up daily.
 BaseLine
• Baseline means ready for release.
• A baseline is a formally accepted version of a
software configuration item.
• Activities during this process:
• Facilitate construction of various versions of
an application.
 Change Control:
• Change control ensures quality and consistency
when changes are made in the configuration
object.
• The change request is submitted to software
configuration manager.
• Activities during this process:
• Changes are committed to the repository.
• The change request will be checked based on the
technical merit, possible side effects and overall
impact on other configuration objects.
• It manages changes and making configuration
items available during the software lifecycle
 Configuration Status Accounting:
• Configuration status accounting tracks each
release during the SCM process.
• Activities during this process:
• Keeps a record of all the changes made to the
previous baseline to reach a new baseline
• Monitor the status of change requests.
• Allows tracking of progress to next baseline
 Configuration Audits and Reviews:
• It ensures that what is built is what is
delivered.
• Activities during this process:
• Configuration auditing is conducted by
auditors by checking that defined processes
are being followed and ensuring that the SCM
goals are satisfied.
• Ensures that changes made to a baseline
comply with the configuration status reports.
• Validation of completeness and consistency
Participant in SCM
• 1. Configuration Manager
• Configuration Manager is the head who is Responsible for identifying
configuration items.
• He/She needs to approve or reject change requests
• 2. Developer
• The developer needs to change the code as per standard development
activities or change requests.
• The developer should check the changes and resolves conflicts
• 3. Auditor
• The auditor is responsible for SCM audits and reviews.
• Need to ensure the consistency and completeness of release.
• 4. Project Manager:
• Ensure that the product is developed within a certain time frame
• Monitors the progress of development and recognizes issues in the
SCM process
• Generate reports about the status of the software system
• Make sure that processes and policies are followed for creating,
changing, and testing
• 5. User
• The end user should understand the key SCM terms to ensure he has
the latest version of the software
Software Configuration Management
Plan
• The SCMP (Software Configuration management
planning) process planning begins at the early phases
of a project.
• The SCMP can follow a public standard like the IEEE
828 or organization specific standard.
• It defines the types of documents to be management
and a document naming. Example Test_v1
• SCMP defines the person who will be responsible for
the entire SCM process and creation of baselines.
• Fix policies for version management & change control.
• Define tools which can be used during the SCM
process.
• Configuration management database for recording
configuration information.
 SCM Tools
• It is recommended that before selecting any
configuration management tool, have a proper
understanding of the features and select the
tool which best suits your project needs and
be clear with the benefits and drawbacks of
each before you choose one to use
• SmartFrog, CLEAR CASETOOL (CC), SaltStack,
CLEAR QUEST TOOL, TortoiseSVN, IBM
Rational team concert, IBM Configuration
management version management, Razor,
Ansible, etc. There are many more in the list.
 Conclusion:
• Configuration Management helps organizations to systematically
manage, organize, and control the changes in the documents,
codes, and other entities during the Software Development Life
Cycle.
• The primary goal of the SCM process is to increase productivity
with minimal mistakes
• The main reason behind configuration management process is
that there are multiple people working on software which is
continually updating. SCM helps establish concurrency,
synchronization, and version control.
• A baseline is a formally accepted version of a software
configuration item
• Change control is a procedural method which ensures quality and
consistency when changes are made in the configuration object.
• Software Configuration audits verify that all the software product
satisfies the baseline needs.
• The SCM process planning begins at the early phases of a project.
• Git, Team foundation Sever and Ansible are few popular SCM tools
 Change Management Process
• Change management process helps you to
manage all requests for change within your
project.
• By using this Change Process, you can:
• Identify requests for change
• Confirm the feasibility of each change.
• Control the way that change is undertaken.
• Manage the approval of change
 Any Change management software should have the
following 3 Key features:
• Concurrency Management:
• When two or more tasks are happening at the same time, it is
known as concurrent operation.
• means that the same file being edited by multiple persons at the
same time.
• If concurrency is not managed correctly with SCM tools, then it
may create many issues.
• Version Control:
• SCM uses archiving method or saves every change made to file.
• With the help of archiving or save feature, it is possible to roll back
to the previous version in case of issues.
• Synchronization:
• Users can checkout more than one files or an entire copy of the
repository.
• The user then works on the needed file and checks in the changes
back to the repository.
• They can synchronize their local copy to stay updated with the
changes made by other team members.
 Eight-Step Change Management
Process
• Step 1: Urgency Creation
• A change is only successful if the whole
company really wants it.
• If you are planning to make a change, then you
need to make others want it.
• You can create urgency around what you want
to change and create hype.
• Use statistics and visual presentations to
convey why the change should take place and
how the company and employees can be at
advantage.
• Step 2: Build a Team
• If your convincing is strong, you will win a lot of
people in favour of change.
• You can now build a team to carry out the change
from the people, who support you.
• Since changing is your idea, make sure you lead
the team.
• Organize your team structure and assign
responsibilities to the team members. Make them
feel that they are important within the team.
• Step 3: Create a Vision
• When a change takes place, having a vision is a
must.
• When you have a clear vision, your team
members know why they are working on the
change initiative and rest of the staff know
why your team is doing the change.
• Step 4: Communication of Vision
• Deriving the vision is not just enough for you
to implement the change.
• You need to communicate your vision across
the company.
• Step 5: Removing Obstacles
• No change takes place without obstacles.
• Once you communicate your vision, you will only be
able to get the support of a fraction of the staff.
Always, there are people, who resist the change.
• Sometimes, there are processes and procedures that
resist the change too! Always watch out for obstacles
and remove them as soon as they appear. This will
increase the morale of your team as well the rest of
the staff.
• Step 6: Go for Quick Wins
• By quick wins, your team will have a great
satisfaction and the company will immediately
see the advantages of your change initiative.
• But always remember to keep the eye on the
long-term goals as well.
• Step 7: Let the Change Mature
• Many change initiatives fail due to early
declaration of victory.
• If you haven't implemented the change 100% by
the time you declare the victory, people will be
dissatisfied when they see the gaps.
• Therefore, complete the change process 100% and
let it be there for sometime.
• Let it have its own time to get integrated to the
people's lives and organizational processes before
you say it 'over.'
• Step 8: Integrate the Change
• continuous monitoring mechanism in place in
order to monitor whether every aspect of the
change taking place in the organization.
Risk Management
Risk management includes three main activities.
• 1. Risk Identification
• Risk identification is the first step in risk management.
• Some of the most common techniques which can be applied to
identify different risks are using risk templates, interviewing the
stakeholders, project retrospectives (The Project Retrospective
dedicates time to reviewing a completed project and learning from
both the successes and the failures so the team and organization
can improve how they work going forward.) etc.
• 2. Risk Analysis
• Risk analysis is the next step of risk management.
• You first need to categorize the risks and then need to determine
the level of risk by specifying likelihood and impact of the risk.
• 3. Risk Mitigation or Risk Control
• After assessing the risk in your project you must control them.
• You can use options like mitigation, contingency to control the
risks.
 Risk management includes the
following tasks:
• Identify risks and their triggers
• Classify and prioritize all risks
• Craft a plan that links each risk to a mitigation
• Monitor for risk triggers during the project
• Implement the mitigating action if any risk
materializes
• Communicate risk status throughout project
checklist is best practices for managing risk on
your software development
• Always be forward-thinking about risk management.
• Use checklists, and compare with similar previous
projects.
• Prioritize risks, ranking each according to the severity
of exposure.
• Develop a top-10 or top-20 risk list for your project.
Like most project managers, you can probably reuse
this list on the next project!
• As practicable, split larger risks into smaller, easily
recognizable and readily-manageable risks.
• Strongly encourage stakeholders to think proactively
and communicate about risks throughout the entire
project.
 Following are the categories of the
risk:
1. Project risk
• It identifies the potential schedule, resource,
stakeholders and the requirements problems and
their impact on a software project.
2. Technical risk
• If the technical risk is real then the
implementation becomes impossible.
• It identifies potential design, interface, verification
and maintenance of the problem.
3. Business risk
If the business risk is real then it harms the project
or product.
 RMMM Plan(Risk
Mitigation,Monitoring,Management)
• It can be organized into a separate
• Risk Mitigation,
• Monitoring and
• Management Plan.
• The RMMM plan documents all work
performed as part of risk analysis and is used
by the project manager as part of the overall
project plan.
• Risk mitigation is a problem avoidance
activity.(prevent from the risk)
• Risk monitoring is a project tracking activity
• Risk Management is proactive activity.
• Example Late Delivery Project.
 Software Measurement Metrics
• Measurements and Metrics A measurement is an
indication of the size, quantity, amount or
dimension of a particular attribute of a product or
process. For example the number of errors in a
system is a measurement.
• A Metric is a measurement of the degree that any
attribute belongs to a system, product or process.
For example the number of errors per person
hours would be a metric.
• Thus, software measurement gives rise to
software metrics.
 Software Measurement Metrics

• Software metrics is a standard of measure that

contains many activities which involve some
degree of measurement. It can be classified
into three categories:
• product metrics,
• process metrics, and
• project metrics.
 Software Size Estimation
• Estimation of the size of software is an essential
part of Software Project Management. It helps the
project manager to further predict the effort and
time which will be needed to build the project.
• Techniques.
• 1. LOC(Line of Code)
• 2. FP(Function Point)
• 3. Emperical Estimation Model--COCOMO
Model, Estimation for Agile Development
 LOC
• Source lines of code (SLOC or LOC) is a
software metric used to measure the size of a
software program by counting the number of
lines in the text of the program's source code.
 Measurement methods

• There are two major types of SLOC measures:

1. physical SLOC (LOC) and
2. logical SLOC (LLOC).
• definition of physical SLOC is a count of lines in the text of
the program's source code including comment lines. Blank
lines are also included.
• In this case blank lines in excess of 25% are not counted
toward lines of code.
• Logical LOC attempts to measure the number of
"statements", excluding comments & Blank lines.
• specific definitions are tied to specific computer languages
• Consider this snippet of C code as an example of
the ambiguity encountered when determining
SLOC:
• for (i = 0; i < 100; i += 1) printf("hello"); /* How
many lines of code is this? */
• In this example we have:
• 1 Physical Lines of Code (LOC)
• 2 Logical Line of Code (LLOC) (for statement and
printf statement)
• 1 comment line
• Depending on the programmer and/or coding standards, the
above "line of code" could be written on many separate lines:
• for (i = 0; i < 100; i += 1)
{
printf("hello");
} /* Now how many lines of code is this? */
• In this example we have:
• 4 Physical Lines of Code (LOC): is placing braces work to be
estimated?
• 2 Logical Line of Code (LLOC): what about all the work writing
non-statement lines?
• 1 comment line: tools must account for all code and comments
regardless of comment placement.
 Advantages
• Very easy to count and calculate from the
developed code.

• Disadvantages:
• LOC is language+ technology dependent.
 Function Points
• Function points are one of the most widely used
measures of software size.
• The basis of function points is that the
"functionality " of the system that is; what the
system performs, is the measure of the system
size.
• In function points, the system functionally is
calculated in terms of the number of function it
implements, the number of inputs, the number of
output etc.
• The original formulation for computing the function
points.
• uses the count of five different parameters, namely,
• External Inputs(EI):The data that comes from outside
our system.
• External Outputs(EO): The data that goes out of the
system.
• External Inquiries(EQ): combination of i/p-o/p
resulting in data retrival.
• Internal Logical Files(ILF):Logical related data that is
present within the system
• External Interface Files(EIF): Other Logical data i.e
referenced by the system but present in other system
• Data Functions
• There are two types of data functions −
• Internal Logical Files
• External Interface Files
• Transaction Functions
• External Inputs
• External Outputs
• External Inquiries
 Counting Function Points
• Step1:
• Each FP is ranked according to complexity.
• There exists pre-defined weights for each FP in
each category.
 Criteria to rank FP

• It depends on organization.
• Depends on past project
 Step 2
• Calculate Unadjusted FP by multiplying each FP by
its corresponding weight factor.
• UFP= ∑ ∑(Zij * Wij)
• Where Zij is count of the number of FP units of
category I is classified as complexity.
• Wij is the weight.
• Example 5 EI🡪Low
• 6 EO 🡪 High
• UFP=5*3 + 6*7(This is not final answer for FP) will
calculate in step 3
 Step 3
• Calculate final FP
• Final FP= UFP * CAF
• Where Complexity adjustment Factor
• CAF is calculated using 14 aspects of processing
complexity.
• 14 questions answered on a scale of 0 to 5.
• 0🡪 No Influnces/Not valid.
• 1🡪 Incidental
• 2🡪Moderate
• 3🡪Average
• 4🡪 Significant.
• 5🡪 Essential.
• CAF =0.65+0.01 * ∑Fi where Fi🡪Answers you have
given
 Numerical
Q) Given the following values, compute FP.
Number of user inputs = 50
Number of user outputs = 40
Number of user enquiries = 35
Number of user files = 06
Number of external interfaces = 04
Assuming all complexity adjustment factors and
weighing factors as average, the function points
for the project will be;
 COCOMO Model
• COCOMO model stands for Constructive Cost
Model.
• It is developed by Barry Bohem.
• It is a hierarchy of software cost estimation model.
• Hierarchy has 3 models.
• 1. Basic Model
• 2. Intermediate Model.
• 3. Detailed Model.
 Basic Model.
• It estimates the software in a rough and quick
manner.
• Mostly useful for small & medium sized
software.
• 3 modes of development.
• 1. Organic Mode
• 2.semi-Detached Mode
• 3.Embedded Mode.
 Intermediate Model.
• The Intermediate Model estimates the
software development effort by using fifteen
cost driver variables besides the size variable
used in Basic COCOMO
• Four areas for drivers
– Product.
– Computer.
– Personnel.
– Project.
 Intermediate Model: Cost Driver
Categories
• Product Attributes
– RELY --- Required Software Reliability
– DATA --- Data Base Size
– CPLX --- Software Product Complexity
• Computer Attributes
– TIME --- Execution Time Constraint
– STOR --- Main Storage Constraint
– VIRT --- Virtual Machine Volatility
– TURN --- Computer Turnaround Time
• Personnel Attributes
– ACAP --- Analyst Capability
– AEXP --- Applications Experience
– PCAP --- Programmer Capability
– VEXP --- Virtual Machine Experience
– LEXP --- Programming Language Experience
• Project Attributes
– MODP --- Modern Programming Practices
– TOOL --- Use of Software Tools
– SCED --- Required Development Schedule
 Intermediate Model: When Should
You Use It
• The Intermediate Model can be applied across
the entire software product for easily and
rough cost estimation during the early stage
• or it can be applied at the software product
component level for more accurate cost
estimation in more detailed stages
 Effort Adjustment factor
The effort adjustment factor use 15 cost drivers that are
grouped into four categories:
• Product
• Computer/Hardware
• Personnel
• Project

Note: Each cost driver has been rated on a six-point

ordinal scale ranging from low to high importance.
Product of all effort multipliers leads to EAF.
 Detailed Model
• Phase-sensitive Effort Multipliers
The effort multipliers for every cost drivers are
different during the software development
phases
• Module-Subsystem-System Hierarchy
The software product is estimated in the three
level hierarchical decomposition. The fifteen
cost drivers are related to module or
subsystem level
• Detailed COCOMO Model:
Module-Subsystem-System
• Module level
– cost drivers tend to vary at the lowest level
– CPLX, PCAP, VEXP, LEXP
• Subsystem Level
– cost drivers tend to vary from subsystem to subsystem, but
are the same for modules in a sub-system
– RELY, DATA, TIME, STOR, VIRT
• System Level
– overall project relations such as nominal effort and
schedule equations
• Detailed COCOMO Model: Equations
• Detailed Model uses the same equations for
estimations as the Intermediate Model
• Detailed Model uses a
very complex procedure to calculate
estimation. The procedure uses the DSIs for
subsystems and modules, and module level
and subsystem level effort multipliers as
inputs
• Detailed COCOMO Model: When Should You
Use It?
• The Detailed Model can estimate the staffing,
cost, and duration of each of the
development phases, subsystems, modules
• It allows you to experiment with different
development strategies, to find the plan that
best suits your needs and resources