Software Engg Lab Manual

Chandigarh School of Business Jhanjeri, Mohali-140307
Department of Computer Applications
Check-list for Lab Course
Sr. No. Contents Yes/No

1. Institute V/M; Department V/M/PEO; PO/PSO Statements Yes
2. Academic Calendar Yes
3. Lab Course Syllabus Yes
4. Lab Course Data Sheet (with Complete details) Yes
5. Lab Course Outcomes – Assessment Plan Sheet Yes
6. Time Table of the Concerned Faculty Member Yes
7. Detailed Lab Course Coverage Yes
8. Lab Manuals Yes
9. Quiz/Viva Sample Questions Yes
10. Continuous Evaluation ( Lab Evaluation Sheets)

11. Sample Experiment Files (Two best , Two average & Two poor students)
12. Gaps & Plans for Add-on Experiments
13. Value Aided Experiments/Design Experiment/Open Ended Experiments
Any Innovative Method Adopted; Description
14. (I.e. Projects/ charts/ PPTs/ Videos etc.)
15. Internal Awards Compilation Record (on Attached Performa)
16. Lab Course Outcomes Assessment (For NBA), Corrective Actions on CO Attainments
Prepared by: Checked by: Approved by

(Ms. Shivani Thakur) (PAQIC Members) HOD
Chandigarh School of Business
Jhanjeri, Mohali-140307
VISION & MISSION

Institute Vision and Mission

VISION
To emerge as Institution of Technical excellence imparting professional education
for sustainable development of society.
MISSION
 To provide quality technical education through state-of-the- art infrastructure
and well qualified and experienced faculty.
 Having academic flexibility through strong industry academia interactions.
 Focus on students' employability, entrepreneurship, higher education and
competitive examinations.
 Inculcate ethical and moral values in students.
Department Vision and Mission

Vision
To provide imperative skills to students for meeting industry needs, and to become
responsible engineers, entrepreneurs and citizens.
Mission
 To educate the students in the field of Computer-Science with ever-changing
technologies and skills.
 To enable the students in solving real-time problems and make use of new
technologies.
 To have industry collaboration and interaction with professional societies for
continuous development.
 To help students in becoming successful entrepreneurs
PROGRAMME OUTCOMES (POs)
Computer Science & Engineering Graduates will be able to:
PO1: Engineering knowledge: Apply the knowledge of mathematics, science, engineering

fundamentals, and an engineering specialization to the solution of complex engineering problems.
PO2: Problem analysis: Identify, formulate, research literature, and analyze complex engineering
problems reaching substantiated conclusions using first principles of mathematics, natural sciences,
and engineering sciences.
PO3: Design/development of solutions: Design solutions for complex engineering problems and
design system components or processes that meet the specified needs with appropriate consideration
for the public health and safety, and the cultural, societal, and environmental considerations.
PO4: Conduct investigations of complex problems: : Use research-based knowledge and research
methods including design of experiments, analysis and interpretation of data, and synthesis of the
information to provide valid conclusions
PO5: Modern tool usage: Create, select, and apply appropriate techniques, resources, and modern
engineering and IT tools including prediction and modeling to complex engineering activities with an
understanding of the limitations.
PO6: The engineer and society: Apply reasoning informed by the contextual knowledge to assess
societal, health, safety, legal and cultural issues and the consequent responsibilities relevant to the
professional engineering practice.
PO7: Environment and sustainablity: Understand the impact of the professional engineering solutions
in societal and environmental contexts, and demonstrate the knowledge of, and need for sustainable
development.
PO8: Ethics: Apply ethical principles and commit to professional ethics and responsibilities and
norms of the engineering practice.
PO9: Individual and team work: Function effectively as an individual, and as a member or leader in
diverse teams, and in multidisciplinary settings.
PO10: Communication: Communicate effectively on complex engineering activities with the

engineering community and with society at large, such as, being able to comprehend and write
effective reports and design documentation, make effective presentations, and give and receive clear
instruction
ACADEMIC
CALENDAR
LAB
COURSE SYLLABUS
Lab Course Syllabus

Task 1:- Identify project scope and objective of given problem:
a. College automation system.
b. Banking Management System.
Task 2:- Develop software requirements specification for (1 a.) and (1 b.) problem.
Task 3:- Develop UML Use case model for a problem.
Task 4:- Develop Class diagrams
Task 5:- Represent project scheduling of above-mentioned projects
Task 6:- Use any model for estimating the effort, schedule and cost of software project
Task 7:- Develop DFD model (level-0, level-1 DFD and Data dictionary) of the
project Task 8:- Develop sequence diagram
Task 9:- Develop Structured design for the DFD model developed
Task 10:- Develop the waterfall model, prototype model and spiral model of the product
Task 11:- Explain with reason which model is best suited for the product
Task 12:- Develop a working protocol of any of two problems
Task 13:- Use LOC, FP and Cyclomatic Complexity Metric of above-mentioned problem
Task 14:- Find Maintainability Index and Reusability Index of above-mentioned problem
Task 15:- Using any Case Tool find number of statements, depth and complexity of the prototype
Faculty Sign HOD Sign

Course Data Sheet

COURSE DATA SHEET

Course Code: UGCA1924
Course Name: Software Engineering Laboratory
Program: BCA L: 0 T: 0 P: 4
Branch: Computer Applications Credits: 2
Semester: 4th Contact hours: 4 hours per week
Theory/Practical: Practical Percentage of numerical/design problems: --
Internal max. marks: 60 Duration of end semester exam (ESE): 3hrs
External max. marks: 40 Elective status: Core
Total marks: 100
Prerequisite: -NA-
o requisite: -NA-
Additional material required in ESE: -NA-
Course Outcomes: Students will be able to
CO# Course outcomes

CO1 Elicit, analyze and specify software requirements.
CO2 Analyze and translate a specification into a design
CO3 Realize design practically, using an appropriate software engineering methodology.
CO4 Plan a software engineering process life cycle.
CO5 Use modern engineering tools for specification, design, implementation, and testing
Assignments:
1. Identify project scope and objective of given problem:

College automation system.
Banking Management System.
2. Develop software requirements specification for (1 a.) and (1 b.) problem.

3. Develop UML Use case model for a problem.
4. Develop Class diagrams
5. Represent project Scheduling of above-mentioned projects
6. Use any model for estimating the effort, schedule and cost of software project
7. Develop DFD model (level-0, level-1 DFD and Data dictionary) of the project
8. Develop sequence diagram
9. Develop Structured design for the DFD model developed
10. Develop the waterfall model, prototype model and spiral model of the product
11. Explain with reason which model is best suited for the product
12. Develop a working protocol of any of two problem
13. Use LOC, FP and Cyclomatic Complexity Metric of above-mentioned problem
14. Find Maintainability Index and Reusability Index of above-mentioned problem
15. Using any Case Tool find number of statements, depth and complexity of the
prototype
Reference Books:
1. Software Engineering–A Practitioner’s Approach, Roger S.Pressman, SeventhEdition,

McGrawHill, 2010.
2. The Unified Modeling Language Reference Manual, Grady Booch, SecondEdition,
Addison Wesley, 2005.
3. An Integrated Approach to Software Engineering, Pankaj Jalota, Third Edition,Narosa
Publishing House, 2005.
COURSE PRE-REQUISITES:
C.CODE COURSE DESCRIPTION SEM

NAME
UGCA Software The Software Engineering Lab is aimed to provide your hands on 4th
experience with different aspects of Software Engineering and UML
1924 Engineering
including requirements identification SFS, behavioral and structural
Laboratory
design using UML diagrams, implementation, testing and so on.
COURSE OBJECTIVES:
S.NO. SEDCRIPITION
1. Students will be capable to acquire the generic software development skill through
various stages of software life cycle.
2. Software Engineering is the systematic approach to the development ,operation,
maintenance and retirement of software.
3. Software Engineering is used basic structure modelling, UML.
COURSE OUTCOMES:
SNo. DESCRIPTION PO(1..10) MAPPING
CO1 Licit, analyze and specify software requirements. PO(1,2,8)
CO2 Analyze and translate a specification into a design PO(2,3,10)
CO3 Realize design practically, using an appropriate software PO(1,2,3,6)

engineering methodology.
CO4 Plan a software engineering process life cycle. PO(1,2,6)
CO5 Use modern engineering tools for specification, design, PO(1,3,5)

implementation, and testing
COURSE OUTCOMES VS POS MAPPING (DETAILED; HIGH:3; MEDIUM:2; LOW:1)
CO# DESCRIPTION PO PO PO PO PO PO PO PO PO PO
1 2 3 4 5 6 7 8 9 10
CO1 Licit, analyze 1 2 2 - - - - 1 1 -
and specify
software
requirements.
CO2 Analyze and - 2 2 1 - - - - 2 -
translate a
specification into a
design
CO3 Realize design 2 2 2 1 - 1 - 1 - -

practically, using an
appropriate software
engineering
methodology.
CO4 Plan a software 2 1 2 1 2 - - 1 2 -

engineering process
life cycle.
CO5 Use modern 2 - 2 1 2 - - 1 1 -

engineering tools
for specification,
design,
implementation, and
testing
COURSE OUTCOMES VS POS MAPPING (DETAILED; HIGH:3; MEDIUM:2; LOW:1):

*For
Entire Course, PO /PSO Mapping; 1 (Low); 2(Medium); 3(High) Contribution to PO/PSO
PO1 Basic knowledge PO6 Environment and sustainability
PO2 Discipline knowledge PO7 Ethics
PO3 Experiments and practice PO8 Individual and team work
PO4 Tools Usage PO9 Communication
PO5 Profession and society PO10 Life-long learning
JUSTIFICATION FOR MAPPING
SNO PO JUSTIFICATION
MAPPED
CO1-PO1 L Apply knowledge of basic to solve problem of software engineering.
CO1-PO2 M An ability to apply specific knowledge to solve problems in software

engineering.
CO1-PO3 M Able to perform practices to solve problems in software engineering.
CO1-PO8 L To perform functionality effectively as an individual, and as a member or
leader in diverse/multidisciplinary teams on specific software requirements.
CO1-PO9 L Able to communicate effectively to analyze and specify software
requirements.
CO2-PO2 M Used to translate and analyze complex problems to reach
substantiated conclusions.
CO2-PO3 M Able to perform practices to translate a specification into a design.
CO2-PO4 L Analyze and translate a specification into a design by using appropriate

technologies and tools
CO2-PO9 M Able to communicate effectively in software engineering requirements.
CO3-PO1 M Help to identify the practical aspect of software engineering by applying
the knowledge.
CO3-PO2 M Able to design software engineering methodology and analyze the
complex problems.
CO3-PO3 M Design Solutions For practical and theoretical problems using software
engineering methods.
CO3-PO4 L Realize design practically, using an appropriate technologies and tools

CO3-PO6 L Apply software engineering methodology to demonstrate the knowledge
and need for sustainable development
leader in diverse/multidisciplinary teams on software designing
CO4-PO1 M Plan a software engineering process life cycle
CO4-PO2 L Identify The formulate and understand the software engineering process
life cycle.
CO4-PO3 M Software engineering process life cycle is easily understand and
practically analyzed by using reasoning and knowledge of professional
engineering.
CO4-PO4 L Use modern engineering tools for specification, design, implementation,
and testing

leader in diverse/multidisciplinary teams on specific software design.
CO4-PO9 L Able to communicate effectively in software engineering requirements
CO5-PO1 M The knowledge of implantation and testing provide the methods that can
be apply to complex problems.
CO5-PO3 M Able to design system components and processes to meet the specified
requirements.
CO5-PO4 L Use modern software engineering tools for specification, design,
implementation, and testing
CO5-PO5 M Helps to identify the problems in testing and implementation by using
modern tools and applying appropriate techniques for solution of complex
engineering activities.
leader in diverse/multidisciplinary teams on specific software design,
implementation and testing.
CO5-PO9 L Able to communicate effectively in software engineering requirements.
GAPES IN THE SYLLABUS - TO MEET INDUSTRY/PROFESSION REQUIREMENTS, POs:
SNO DESCRIPTION PROPOSED ACTIONS / ACTION TAKEN

1 Use testing tool such as j-unit. Extra class/Content Beyond Syllabus
2 Using configuration management tool- Libra. extra class/Content Beyond Syllabus
PROPOSED ACTIONS: TOPICS BEYOND SYLLABUS/ASSIGNMENT/INDUSTRY VISIT/GUEST

LECTURER/NPTEL ETC
TOPICS BEYOND SYLLABUS/ADVANCED TOPICS/DESIGN:
SNO DESCRIPTION PROPOSED ACTIONS / ACTION TAKEN

1 Prepare a SRS document in line with the IEEE PPT shared/extra class/Content Beyond Syllabus
recommended standards.
2 Draw Entity Relationship diagram . PPT shared/extra class/Content Beyond Syllabus
1 https://www.javatpoint.com/software-engineering-tutorial
2 https://www.geeksforgeeks.org/software-engineering-introduction-to-software-engineering/
3 https://www.tutorialspoint.com/software_engineering/
4 https://youtu.be/FBR0_YLkB0Q
5 https://youtu.be/5EluCeNlQC4
6. https://youtu.be/USUI7SH0OJ8
WEB SOURCE REFERENCES:
DELIVERY/INSTRUCTIONAL METHODOLOGIES:
 CHALK & ☐ STUD.  WEB RESOURCES  NPTEL/OTHERS
TALK, PPT ASSIGNMENT
 LCD/SMART ☐ STUD. ☐ ADD-ON COURSES ☐ WEBNIARS
BOARDS SEMINAR
S
ASSESSMENT METHODOLOGIES-DIRECT
☐ ASSIGNMENTS  STUD. SEMINARS  TESTS/MODEL  UNIV.

EXAMS EXAMINATION
 STUD. LAB  STUD. VIVA ☐ MINI/MAJOR ☐ CERTIFICATIONS
PRACTICES PROJECTS
☐ ADD-ON COURSES ☐ OTHERS
ASSESSMENT METHODOLOGIES-INDIRECT
 ASSESSMENT OF COURSE OUTCOMES (BY  STUDENT FEEDBACK ON FACULTY
FEEDBACK, ONCE) (TWICE)
☐ ASSESSMENT OF MINI/MAJOR PROJECTS BY ☐ OTHERS
EXT. EXPERTS
INNOVATIONS IN TEACHING/LEARNING/EVALUATION PROCESSES:
1. Group Discussion.
2. PPT by students.
3. Open book test.
4. Online courses
5. MCQ’s
Prepared by Approved by
(Ms. Shivani Thakur) HOD
COURSE PLAN
VISION:
To provide imperative skills to students for meeting industry needs, and to become responsible engineers,
entrepreneurs and citizens.
MISSION:
 To educate the students in the field of Computer-Science with ever-changing technologies and
skills.
 To enable the students in solving real-time problems and make use of new technologies.
 To have industry collaboration and interaction with professional societies for continuous
development.
 To help students in becoming successful entrepreneurs.
PROGRAM EDUCATIONAL OBJECTIVES:
1. Become competent Computer Professionals.

2. Have abilities to analyze the requirements of software and provide solutions through efficient
product designs.
3. Have successful career and meet the requirements of Indian and other Multi-National Companies.
4. Have exposure to advanced technologies, technical skills and opportunities to work as team
members on multidisciplinary projects
Contact L Total
Subject: Software Engineering Semester
Hour: 4 hours 4 = 4
Laboratory (UGCA1924) : th
4 per week
Branch: Computer Applications Faculty: Shivani Thakur
Course
Lecture Proposed Actual
Topics/Sub Topics Outcome Remarks
No. Addressed Date Date
Identify project scope and objective
of given problem:
1. CO1
2. Identify project scope and objective CO2

of given problem:
b. Banking Management System.
Develop software requirements

3. specification for CO2,CO4
4. Develop software requirements CO2

specification for
b. Banking Management System
5. Introduction to Visual Paradigm CO2,CO5
6. Introduction to UML and Use case model. CO3
Develop UML Use case model for a

7. problem. CO3
Introduction to class diagrams
8.
Develop Class diagrams
9. CO3,CO5
10. Represent project Scheduling of
CO1
above- mentioned projects
Use any model for estimating the
11. effort, schedule and cost of CO4
software
project
Develop DFD model (level-0, level-1
12. DFD and Data dictionary) of CO2
the project
13. Develop sequence diagram CO4
Develop Structured design for the

14. CO1,CO2
DFD model developed
Develop the waterfall model, prototype
15. model and spiral model of the product CO1
Explain with reason which model
16. CO1,CO2
is best suited for the product
Develop a working protocol of any of
17. two problem CO5
Use LOC, FP and Cyclomatic
18. Complexity Metric ofJhanjeri,
above- Mohali-140307
CO4,CO5
mentioned problem Department of Computer Applications
Find Maintainability Index and
19. Reusability Index of above- CO4
mentioned
problem
Using any Case Tool find number of
20. statements, depth and complexity of CO5
the prototype
Text Books/ Reference Books:
T/R Description
R1 Software Engineering–A Practitioner’s Approach, Roger S.Pressman, SeventhEdition,

McGraw-Hill, 2010.
R2 The Unified Modeling Language Reference Manual, Grady Booch, SecondEdition,
Addison Wesley, 2005.
R3 An Integrated Approach to Software Engineering, Pankaj Jalota, Third Edition,Narosa
Publishing House, 2005.
WEB SOURCE REFERENCES
1 https://www.javatpoint.com/software-engineering-tutorial
2 https://www.geeksforgeeks.org/software-engineering-introduction-to-software-engineering/
3 https://www.tutorialspoint.com/software_engineering/
4 https://youtu.be/FBR0_YLkB0Q
5 https://youtu.be/5EluCeNlQC4
6. https://youtu.be/USUI7SH0OJ8
Prepared by Approved by
((Ms. Shivani Thakur) (HOD)
Time Table of the

Concerned
Coordinator
Time Table of Even Semester
Ms. Shivani Thakur
I II III IV V VI VII VIII IX
12:00 2:20 3:50
9:30 AM- 10:20 AM- 11:10 AM- PM- 12:50 PM- 1:35 PM-2: PM- 3:05PM-3:50 PM-
10:20 AM 11:10 AM 12:00 AM 12:50 1:35 PM 20PM 3:05 PM 4:05P
PM PM M
SE LAB
Monday
BCA 4A2
SE LAB
Tuesday
BCA 4A1
Wednesday BREAK
SE LAB
Thursday
BCA 4B1
SE LAB SE LAB
SE LAB
Friday TUTE TUTE
BCA 4B BCA 4B2 BCA 4A
Subject Teacher’s Signature H.O.D’s Signature

Jhanjeri,
Software Engineering Laboratory (UGCA1924) Mohali-140307
-Viva Questions
Sr. No Experiment No. Questions
Experiment -1
1 What is college automation system?
2 Experiment -1 What are the applications of bank management system?
What are the software requirements specifications (SRS) for college
3 Experiment -2 management system?
What are the software requirements specifications for student information

4 Experiment -2 management system?
Experiment -3
5 What is UML in software engineering?
Experiment -3
6 Why do we create UML diagrams?
Experiment -3
7 What is use case model in software engineering?
Experiment -4
8 How do you create a class diagram?
9 Experiment -4 What are the essential elements of A UML class diagram?
10 Experiment -5 What is project scheduling with example?
Experiment -5
11 How do you represent a project schedule?
Experiment -6
12 What is software testing estimation?
Experiment -6
13 Define COCOMO Model?
Experiment -7
14 What is DFD in project?
Experiment -7
15 What is 0-level DFD with example?
Experiment -8
16 What is level -1 DFD with example?
Experiment -8
17 What is sequence diagram in software engineering?
Experiment -8
18 What is purpose of sequence diagram?
19 Experiment -9 How DFD model of a system are developed in software engineering?
Experiment -10 What is waterfall model and spiral model?
20
Experiment -10 Define prototype model?
21
22 Experiment -11 Department
Which process model is of
bestComputer
and why? Applications
23 Experiment -11 How do I choose the right process model?
24 Experiment -12 What are the problems of software engineering?
25 Experiment -13 What is cyclomatic complexity explain with suitable examples?
26 Experiment -13 How is cyclomatic complexity calculated in software engineering?
27 Experiment -14 What is Reusability Index in software engineering?

28 Experiment -14 What is maintainability index in code metrics?
What is CASE tool in software engineering?
29 Experiment -15
Experiment -15 What are the features of CASE tools?
30
LAB
MANUAL
Experiment 1
Aim: Identity project scope and objective of given problem:
a) College automation system.
b) b) Banking Management System.
College automation system
FUTURE SCOPE
It is more efficient and convenient for the colleges. It reduces the man power needed to perform different
tasks by reducing the paper work’s needs. If all the works are done by computer there will be no chance
of errors. More ever storing and retrieving of the information is easy, so work can be done speedily and
in time.
Features:
• User friendly
• Very less paper works
• Computer operator control
• Responsiveness increases
Objectives:
The main objective of the system is to reduce the consumption of time during maintenance of record of the
college students. The head of the department’s role also include the maintenance of the details of the
teacher. He can also maintain the attendance of each of his students under his department. He will fill in
the internal of the student that will directly go to the examination department in a tabular format so that
they do not have any hesitation in calculating the final marks of the students. In other words our college
automation system has, following objectives:
• Simple easy database maintained.

• To manage the tasks related to the students and authorities.
• User interface are user friendly.
Banking Management System

Project Scope
Banking activities are considered to be the life blood of the national Economy. Without banking services,
trading and business activities cannot be carried on smoothly. Banks are the distributors and protectors of
liquid capital which is of vital significance to a developing country. Efficient administration of the banking
system helps in the economic Growth of the nation. Banking is useful to trade and commerce.
Project Objective
• To allow only authorized user to access various function and processed available in the system.
• Locate any A/C wanted by the user.

• Reduced clericalwork as most of the work done by computer. • Provide greater speed & reduced
time consumption.
A computer based management system is designed to handle all the primary information required to
calculate monthly statements of customer account which include monthly statement of any month.
Separate database is maintained to handle all the details required for the correct statement calculation and
generation.
This project intends to introduce more user friendliness in the various activities such as record
updation, maintenance, and searching. The searching of record has been made quite simple as all the
details of the customer can be obtained by simply keying in the identification or account number of that
customer.
Similarly, record maintenance and updating can also be accomplished by using the account number with
all the details being automatically generated. These details are also being promptly automatically updated
in the master file thus keeping the record absolutely up-to-date.
The main objective of our project is providing the different typed of customers facility, the main objective
of this system is to find out the actual customer service. Etc.
• It should fulfill almost all the process requirements of any Bank.

• It should increase the productivity of bank by utilizing the working hours more and more, with
minimum manpower.
This project includes the entire upgraded feature required for the computerization banking system. This
system is very easy to use, so that any user can use without getting pre-knowledge about this. It’s very
much user friendly. This system is completely GUI based and can be used by mouse and as well as
keyboard. This system is melded in such a way that has got all features to upgrade without making much
change in existing components.
Experiment 2
Aim: Develop software requirements specification for
(1.a).college automation system.
(1.b).bank management system.

Introduction
The main objective of this project is to maintain information about students, employees and other
activities like attendance, student marks ,fee payment ,and salary payment ,etc. the information is stored
for decision making in the future for a business process within an organization. This is a desktop
application.
Purpose
This document describes the software requirements specifications for the college management system that
provides the access and management of information of different modules in a college-like students,
guardians, teachers/faulty, finance ,examination, HR. our project is based on a database, which stores and
maintains the information of different modules within the system. the advantages of the management
system is avoid entries in hard copies and it saves the burden of hard copies of data. The system is a
desktop application and GUI for this system is developed in c#. the database for this management system
is created in SQL there are two users for this system 1.Admin 2.Teacher .
The purpose of this document is to retrieve and analyze the ideas that define the product and requirements
that the user needs. This document describes the details of our product, its parameter, and its goals. This
SRS document describes the target, audience, user interface of product and Software/Hardware
requirements of our product. This document also describes the problem we have faced during the
designing and implementation of the product and also describes how we have solved this problem and
make our product more efficient. The management system saves the human power and time cost to
perform the same task. The data in the database can be saved for a long time and can be used for different
purposes in the future. In management systems, there is a minor chance of losing the data. This document
also defines how customers and users see our product and understand
the functionality of the product. This document will help the developers/designers in case of maintenance
of the software product.
Key Focus and Abbreviations

When writing this SRS for College Management System the following terminologies are used:
• CMS: College Management System.

• C#: Pronounced as C sharp. It is an object-oriented programming language in which
reusable components build for a wide variety of applications.
• GUI: Graphical User Interface.
• DBMS: Database Management System.
• SQL: Structured Query Language, used to create the database.
• SQL Server: SQL Server is a database management system in which database is created and
manages the database like “update”, “Delete” and insert a new record in the database.
Problem Statement
“Manual College systems were paper-based and difficult to maintain, expensive, more manpower required
and unable to handle large records, the previous system was not efficient, not effective and there were
issues of redundancy and consistency.”
Proposed System
In this project, the system is proposed by understanding the issues in the existing system. In this
management system the problems are solved that were in the previous system by shifting on a
computerized system of the modern age. The database is used to store the data at the backend of the
system. The graphical interface GUI is developed in C#. In a certain way get the data from the user and
store it into the database. Reports of stored data are generated through Crystal reports. The system that is
proposed provides consistent and redundancy free data in storage and should be more efficient .This
system provides the security of data by authentication of users and in this project right of users are defined.
In this system, admin is the main user of the system who has full rights of all modules within the proposed
system and the other user which is an employee of college also can be a teacher within the college has
limited access to the system like students attendance and marks of the students are managed by the
employee. In this product, different reports can be generated, pay slips of employee salary, fee report of
fee payment if students, student details, attendance report, etc.
The main modules which are focused on this project:
• Student management
• Employee management
• Student Fee management
• Employee salary payment

• User registration
• Internal Marks of students
• Attendance of students
• Reports of all modules (Crystal Reports)
• Project Scope
As Colleges are growing day by day more and more, and also increasing the complexity of storing
information of students and related to the college system, they face many related issues: attendance and fee
of students, salary details of employees, etc. This project is based on the educational institute system where
this application gives maximum services in a single software product that is used by teacher and system
administration. This project is based on a desktop application that is sharing information on different
departments in a college.
In this project that includes C# and SQL. C# is used to design the GUI for the application by which the
user can interact with software applications. The SQL Server is used for creating the database in which
different information will store. The main focus of this project is to give the best GUI for the users and
provide the many modules in a single product. Admin can view all of the information that is stored in the
database through application and admin also can modify this information because the admin has full access
to the system. The teacher can view and modify the information related to students, teachers have limited
access. This project can adjust any additional module at any time.
Target Audience and Reading Suggestions

This document is to be read by the development team, the project managers, marketing staff, testers, and
documentation writers. The software engineer/developer and project managers need to become
intimately familiar with the SRS. Others involved need to review the document. Testers need an
understanding of the system features to develop meaningful test cases and give useful feedback to the
developers. The developers need to know the requirements of the software product they need to build.
This document is for general discussions on the implementation decisions regarding the College
Management System. The user of the product should have the concepts of RDMS, SQL, interfaces, and
classes.
Operating Environment
The CMS is expected to be deployed in a real environment to manage the DBMS inside the college. The
centralized database is used to store the information. The user only within the college (members of college
staff) can use this management system. Users outside form the college cannot access the management
system. This application is developed for windows operating system that can be run on Windows XP and
above.
The database is used in different departments within a branch of the college. The database used to store the
information is the centralized database. The software we have developed will be installed on different
computer systems within a college and software will be connected to a centralized database through LAN
within a college and then the user can interact with the system and can store the data and other users can
get access the stored through a centralized database.
User Types and Authorities

This management system is controlled by the teachers and system administrators. In this system, admin is
the main user who has full access to the management system .admin can view and modify all information
that is stored in the database. Admin can view and modify the student’s records like student’s profile,
attendance, fee, results, and details of teachers and other employees in college, their personal information
and their attendance for their salaries.
Teachers have access to view and modify the student’s information like their attendance, marks of exams
to generate the progress report of students. When the teacher update’s the student’s information then
admin can view this information.
Design and Implementation Constraints

During the implementation of the product, different challenges are faced. Choosing the interface for the
management system was a paramount issue. Connecting the database with the application was a major
problem.For connecting the database we had to create our account in ORACLE and then we had to
download the driver(software). The connection of the database that is created in ORACLE with C# is not
very simple as like SQL. So the installation of ORACLE driver(software) is necessary to create a
connection between ORACLE and C#. But after installing the required driver it creates a problem in
installing and connecting with a server in the oracle server, so we decided to leave the oracle and then we
choose the SQL server to create the database.
The SQL Server is easy to install and connect with a server in SQL it is very easy to understand the
implementation of the database and also easy to create a new database and connect with the GUI
application.
Methodology of Project
We developed our product using the software development life cycle. In the development of our product,
we use the Agile model. The Agile model is a model of SDLC which is a combination of two process
models incremental and iterative. CMS is developed on the basis of incremental process model of the
Agile model which allows the user to divide the large project into different parts/ modules.
In the incremental model the versions/parts of the system are delivered to the user after a regular interval
of time, to get feedback from the user that is it cleared or he/she want any more changes in the given
module. If the user wants any type of change in the product then it is possible through the incremental
model.After the decided time each new part of the product is developed and delivered to the user and then
at the end when all parts are developed, all modules/parts are combined in a way to develop the full
product to deliver to the user in the form of finished/complete application as user’s requirements.
Communication between client and developer is an important part of the agile model. The product will
fulfill the user’s requirement in the case when there is maximum communication between developer
and client so the application will be more accurate. The finished product should accept the changes in
the future.
Develop software requirements specification for (1.b).bank

management system.
Table of Contents
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Overview
1.4 Additional Information
2. General Description
3. Functional specifications
3.1 Login
3.2 Validation
3.3Payment of money
3.4Transfer of money
3.5Transaction report
4. Interface Requirements
4.1 GUI
4.2 Hardware Interface
4.3 Software Interface

5. Performance Requirements
6. Constraints
7. Performance
7.1 Security
7.2 Reliability
7.3 Availability
7.4 Maintainability
7.5 Reusability
1. Introduction
This document gives detailed functional and nonfunctional requirements for the bank management
system. This product will support online banking transaction. The purpose of this document is that the
requirements mentioned in it should be utilized by software developer to implement the system.
1.1 Purpose
Online banking system provides is specifically developed for internet banking for Balance Enquiry, Funds
Transfer to another account in the same bank, Request for cheque book/change of address/stop payment of
cheques , Mini statements (Viewing Monthly and annual statements).
The Traditional way of maintaining details of a user in a bank was to enter the details and record them.
Every time the user need to perform some transactions he has to go to bank and perform the necessary
actions, which may not be so feasible all the time. It may be a hard-hitting task for the users and the
bankers too. The project gives real life understanding of Internet banking and activities performed by
various roles in the supply chain. Here, we provide an automation for banking system through Internet.
Internet banking system project capturesactivities performed by different roles in real life banking which
provides enhanced techniques for maintaining the required information up-to-date, which results in
efficiency. The project gives real life understanding of Internet banking and activities performed by
various roles in the supply chain.
1.2 Scope
This Product will automate of banking transaction process.This Project investigates the entry threshold
for providing a new transaction service channel via the real options approach, where the entry
threshold is established by using an Internet banking system designed for the use of normal
users(individuals), Industrialists, Entrepreneurs, Educational Institutions(Financial sections),
Organizations and Academicians under transaction rate uncertainty.
1.3 Overview
The system provides easy solution to banks.
• Overview: The SRS will include two sections, namely:

• Overall Description: This section will describe major components of the system,
interconnections, and external interfaces.
• Specific Requirements: This section will describe the functions of actors, their roles in the
system and the constraints faced by system.
2. General description
2.1 Product Perspective:
The client will have client interface in which he can interact with the banking system. It is a web based
interface which will be the web page of the banking application. Starting a page is displayed asking the
type of customer he is whether ordinary or a corporate customer. Then the page is redirected to login
page where the user can enter the login details. If the login particulars are valid then the user is taken to a
home page where he has the entire transaction list that he can perform with the bank. All the above
activities come under the client interface.
The administrator will have an administrative interface which is a GUI so that he can view the entire
system. He will also have a login page where he can enter the login particulars so that he can perform
all his actions. This administrative interface provides different environment such that he can maintain
database & provide backups for the information in the database. He can register the users by providing
them with username, password & by creating account in the database. He can view the cheque book
request & perform action to issue the cheque books to the clients.
2.2 Software Interface:
Front End Client:

The system is a web based application clients are requiring using modern web browser such as
Mozilla Firefox 1.5, PHP.
* Web Server:
The web application will be hosted on one of the apache server.
* Back End:
We use backend as MY SQL.
3. Functional Specifications
This section provides the functional overview of the product. The project will require the PHP as a front
end and at the back end the database MYSQL will be running. Various functional modules that can be
implemented by the product will be
1. Login
2. Validation
3. Get balance information
4. Withdrawal of money
5. Transfer Money
6. Customer info.
3.1 Login:
Customer logins by entering customer name & a login pin.
3.2 Validation:
When a customer enters the ATM card, its validity must be ensured. Then customer is allowed to enter the
valid PIN. The validation can be for following conditions
• Validation for lost or stolen card

• When card is already reported as lost or stolen
• Then the message “Lost/Stolen card!!!”
• Validation for card’s expiry date
If the card inserted by the customer has crossed the expiry date then the system will prompt “Expired Card”.
Validation for PIN

After validating the card, the validity of PIN must be ensured. If he/she fails to enter valid code for three
times then the card will not be returned to him. That means the account can be locked. The counter for
number of logins must be maintained
Get balance information:
This system must be networked to the bank’s computer. The updated database of every customer is
maintained with bank. Hence the balance information of every account is available in the database and
can be displayed to the customer.
3.3 Payment of Money:
A customer is allowed to enter the amount which he/she wishes to withdraw. If the entered amount is less
than the available balance and if after withdraw if the minimum required balance is maintained then allow
the transaction.
3.4 Transfer of Money:
The customer can deposit or transfer the desired amount of money.

3.5 Transaction Report:
The bank statement showing credit and debit information of corresponding account must be printed by the
machine.
3.6 Technical Issues

This product will work on client-server architecture. It will require an internet server and which will be
able to run PHP applications. The product should support some commonly used browsers such as Internet
Explorer, Mozilla Firefox.
4. Interface Requirements
4.1 GUI
This is interface must be highly intuitive or interactive because there will not be an assistance for the user
who is operating the System. At most of the places help desk should be provided for users convenience.
The screens appearing should be designed in such a manner that it can
draw User attraction towards the new plans for the customers. Also the pin and password confidentiality
should be maintained, this can be done by using asterisks at the password panel.
Proper security messages should be displayed at most of the places.
4.2 Hardware Interface

Various interfaces for the product could be
1. Touch screen/Monitor
2. Keypad
3. Continuous battery backup
4. Printer which can produce the hard copy.
5. Interface that connects the device to bank’s computer.
6. An interface that can count currency notes.
4.3 Software Interface
1. Any windows operating system.
2. The PHP must be installed. For the database handling MYSQL must be installed. These products
are open source products.
3. The final application must be packaged in a set up program, so that the products can be easily installed
on machines. This application must be networked to corresponding banks.
5. Performance Requirements
The system should be compatible enough to hold the general traffic .
It should not get hang or show some other problems arising out due to large no of concurrent users . The
system should be fast enough to meet the customer The high and low temperature should not affect the
performance of the device. An uninterrupted transaction must be performed.
6. Constraints
* The information of all the users must be stored in a database that is accessible by the On- line
Banking System.
* The Online Banking System is connected to the computer and is running all 24hours a day.
* The users access the Online Banking System from any computer that has Internet browsing
capabilities and an Internet connection.
*The users must have their correct usernames and passwords to enter into the Online Banking System.
Design Constraints:
* Software Language Used

The languages that shall be used for coding Online Banking System are c , c++ , java , and HTML. For
working on the coding phase of the Online job portal System Web Sphere Application
Server/WebSphere Application Server CE Server needs to be installed.
7. Database design
In our database design, we give names to data flows, processes and data stores.
Although the names are descriptive of data, they do not give details .So following DFD, our interest is to
build some details of the contents of data flows, processes and data store. A data dictionary is a structured
repository of data about data .It is a set of rigorous definitions of all DFD data elements and data
structures .
8. Performance
• Security
The banking system must be fully accessible to only authentic user.
It should require pin for entry to a new environment.
• Reliability
The application should be highly reliable and it should generate all the updated information in correct
order.
• Availability
Any information about the account should be quickly available from any computer to the authorized user.
The previously visited customer’s data must not be cleared.
• Maintainability
The application should be maintainable in such a manner that if any new requirement occurs then it should
be easily incorporated in an individual module.
• Portability
The application should be portable on any windows based system. It should not be machine specific.
EXPERIMENT 3
Aim: Develop UML case model for a problem.
What is a use case diagram?
In the Unified Modeling Language (UML), a use case diagram can summarize the details of your system's
users (also known as actors) and their interactions with the system. To build one, you'll use a set of
specialized symbols and connectors. An effective use case diagram can help your team discuss and
represent:
• Scenarios in which your system or application interacts with people, organizations, or external
systems
• Goals that your system or application helps those entities (known as actors) achieve
• The scope of your system
When to apply use case diagrams

A use case diagram doesn't go into a lot of detail—for example; don't expect it to model the order in which
steps are performed. Instead, a proper use case diagram depicts a high-level overview of the relationship
between use cases, actors, and systems. Experts recommend that use case diagrams be used to supplement
a more descriptive textual use case.
UML is the modeling toolkit that you can use to build your diagrams. Use cases are represented with a
labeled oval shape. Stick figures represent actors in the process, and the actor's participation in the system
is modeled with a line between the actor and use case. To depict the system boundary, draw a box around
the use case itself.
UML use case diagrams are ideal for:
• Representing the goals of system-user interactions

• Defining and organizing functional requirements in a system • Specifying the context and
requirements of a system
• Modeling the basic flow of events in a use case.
Use case diagram components

To answer the question, "What is a use case diagram?" you need to first understand its building blocks.
Common components include:
• Actors: The users that interact with a system. An actor can be a person, an organization, or an
outside system that interacts with your application or system. They must be external objects that
produce or consume data.
• System: A specific sequence of actions and interactions between actors and the system. A system
may also be referred to as a scenario.
• Goals: The end result of most use cases. A successful diagram should describe the activities and
variants used to reach the goal.
Use case diagram symbols and notation

The notation for a use case diagram is pretty straightforward and doesn't involve as many types of symbols
as other UML diagrams. You can use this guide to learn how to draw a use case diagram if you need a
refresher. Here are all the shapes you will be able to find in Lucidchart:
Use cases: Horizontally shaped ovals that represent the different uses that a user might have.
Actors: Stick figures that represent the people actually employing the use cases.
• Associations: A line between actors and use cases. In complex diagrams, it is important to know
which actors are associated with which use cases.
System boundary boxes: A box that sets a system scope to use cases. All use cases outside the box would
be considered outside the scope of that system. For example, Psycho Killer is outside the scope of
occupations in the chainsaw example found below.
Packages: A UML shape that allows you to put different elements into groups. Just as with component
diagrams, these groupings are represented as file folders.
Use case diagram examples

Railway reservation use case diagram example
You can adapt this template for any process where a customer purchases a service. With attractive color
schemes, text that’s easy to read and edit, and a wide-ranging UML shape library, you’re ready to go!
Click to try out this
template
EXPERIMENT 4
Aim: Develop class diagrams .
Class Diagram Definition | What is a Class Diagram?
A class diagram is a UML diagram type that describes a system by visualizing the different types of
objects within a system and the kinds of static relationships that exist among them. It also illustrates the
operations and attributes of the classes.
They are usually used to explore domain concepts, understand software requirements and describe detailed
designs.
Class Diagram Notations with Examples

There are several class diagram notations that are used when drawing UML class diagrams.
Classes represent the central objects in a system. It is represented by a rectangle with up to 3

compartments.
The first one shows the class’s name, while the middle one shows the class’s attributes which are the
characteristics of the objects. The bottom one lists the class’s operations, which represents the behavior of
the class.
The last two compartments are optional. The class notation without the last two compartments is called a
simple class and it only contains the name of the class.
The interface symbol in class Diagrams indicates a set of operations that would detail the responsibility
The package symbol is used to group classes or interfaces that are either similar in
nature or related. Grouping these design elements using the package symbols
improves the readability of the diagram
Class Diagram Relationships
To learn about the class diagram connector types and the different relationships between classes in detail, refer
to our handy guide on class diagram relationships.
For a full list of class diagram notations/ class diagram symbols refer to this post.
How to Draw a Class Diagram

Class diagrams go hand in hand with object-oriented design. So knowing its basics is a key part of being
able to draw good class diagrams.
When required to describe the static view of a system or its functionalities, you’d be required to draw a
class diagram. Here are the steps you need to follow to create a class diagram.
Step 1: Identify the class names
The first step is to identify the primary objects of the system.
Step 2: Distinguish relationships
Next step is to determine how each of the classes or objects is related to one another. Look out for
commonalities and abstractions among them; this will help you when grouping them when drawing the
class diagram.
Step 3: Create the Structure
First, add the class names and link them with the appropriate connectors. You can add attributes and
functions/ methods/ operations later.
Class Diagram Best Practices

Class diagrams may tend to get incoherent as they expand and grow. It’s best to avoid creating large
diagrams and breaking them down into smaller ones that you can link to each other later. It helps you
improve the readability of your diagrams.
Using the simple class notation, you can quickly create a high-level overview of your system. A detailed
diagram can be created separately as required, and even linked to the first one for easy reference.
The more lines overlap on your class diagrams, the more cluttered it becomes. The reader will only get
confused trying to find the path. Make sure that no two lines cross each other.
Use colors to group common modules. Different colors on different classes help the reader differentiate
between the various groups.
Class Diagram Examples / Templates
EXPERIMENT 5
Aim : Project scheduling.
What is scheduling in project management?
As you might imagine, a project schedule contains more than your average weekly planner notes. Project
scheduling involves creating a document, these days usually a digital document, that details the project
timeline and the organizational resources required to complete each task .The project schedule must be
accessible to every team member. Its purpose is to communicate critical information to the team, so it must
be comprehensive and easy to understand.
How is project scheduling different from planning?

Quite often, these two terms are used interchangeably but they have different roles in the successful
completion of a project. On a higher level, the project plan is the master blueprint while the project
schedule details the specific tasks.
Planning primarily involves selecting the appropriate policies, project methodologies, and procedures
required to deliver the project on time. Scheduling, on the other hand, converts the plans, scope, and cost
into an operational timeline .Project management has its share of challenges, but an intuitive project
management tool can ease things a great deal. Kiss flow Project is built for ease of use. Sign up for a free
trial today!
Why should I create a project schedule?

Project scheduling is important since it plays an effective role in project success. The following are some
of the advantages if you properly create your project schedule. Project scheduling, when done well, makes
the entire project run more smoothly. Committing to the project scheduling process at the beginning of
your project will give you a clear picture of the requirements set before you.It also gives you the chance to
catch issues early and alert clients if a timeline isn’t feasible. Besides being good for you as the project
manager, project scheduling is good for your team.
Everyone knows what to expect and when. Everyone is being held accountable for the same due dates.
Other managers can allocate resources efficiently for your project, and they’ll be able to anticipate when
resources will be available for other projects.
Manage your project schedules better with Kiss flow Project
Sign Up — It’s Free!

What are the steps in the project scheduling process?
How do you create a project schedule? Well, the project scheduling process can be broken down into eight
manageable steps. Follow these and pretty soon you’ll be a scheduling pro.
project scheduling process steps
1. Plan schedule management

The groundwork for a good project schedule is to establish the procedures, company policies, and
documentation guidelines that will govern your project. The plan for schedule management outlines
resources available for the project and the contingencies that may arise. It also lists project stakeholders,
itemizes individuals who must approve the schedule, and lists others who need to receive a copy.
This document also establishes who has the authority to make schedule changes, the process team
members should follow in order to request a change, and a project communication plan to alert the team
of changes made during the course of the project.
2. Define the project activities

This can be as simple as creating a list of tasks that must be completed in order to deliver your project. In
the case of complex projects, it may be helpful to organize these tasks in the form of at, a chart visualizing
tasks and their sub-tasks and to stay organized at work.
One challenge in this part of the project scheduling process is knowing how to divide activities. Consider
the 8/80 rule, which states that a single activity should take between eight and eighty work hours.
In team task management, tasks requiring fewer than eight hours could be grouped with others and tasks
over eighty hours are likely too cumbersome and should be broken down further. Activities should also be
measurable, easily estimated, and related to both a project deliverable and a budgeted cost.
3. Determine dependencies
Once you have all the project activities listed, think through each one carefully to identify which tasks rely
on others to be completed. If you’re building a house, for example, you can’t put the roof on until the
frame is completed. It’s important to correctly define all your dependencies so you can schedule
accurately and avoid project delays.
All-in-one project management solution
Sign Up — It’s Free!
4. Sequence activities
After you’ve established project dependencies among your activities, you can sequence them. At this
point, you aren’t assigning any time to your activities in terms of work hours or due dates. Instead, you’re
focusing on the order in which all project activities should be done so that the most efficient flow is
created.
5. Estimate resources
Each activity in your project will require resources in the form of personnel, subcontractor costs, tools
(physical and/or digital tools like software programs), and workspace. Make sure to consider other
resources that are specific to your industry or project. Estimate the resources needed for each project
activity.Remember that resource allocation will affect your schedule; if the same team member is
responsible for multiple tasks, they can’t be completed at the same time.
6. Estimate durations
This step is pretty obvious but very important. How long will each project activity take? Underestimating
will, of course, put you behind schedule and ultimately frustrate your customer.Overestimating could leave
team members or other resources sitting idle as they wait for antecedent tasks to be completed. The best
way to estimate duration is to use data from similar previous jobs.
If you don’t have any data to work from and there’s no industry standard to which you can refer, an
estimate based on the average of the best, worst, and most likely scenarios.
7. Develop the project schedule

At this point, you should have all the information you need to develop your project schedule. Taking into
consideration the duration and resource requirements of each activity, as well as their dependencies and
proper sequence, you can assign start dates and due dates for each activity.
There are multiple models and formulas for developing the project schedule, including critical path, critical
chain, and resource leveling among others. Each of those methods is worthy of an article in itself, so we
won’t cover them here. Take the time to find a method that works well for you.
For example, Don’t ignore the calendar! Check vacation requests from team members. Don’t forget to
include factors like national holidays, corporate functions, stakeholder events, and other occasions that
may affect your schedule. If the whole company shuts down for a holiday week, you’ll need to add that
time to your due dates and manage customer expectations accordingly.
8. Monitor and control

Unlike the rest of the project scheduling steps, Step 8 is ongoing. As a project manager, you’ll be
monitoring and controlling your project schedule for the duration of the project. This step involves running
reports and assessing the progress of a project against the schedule, managing performance, and
communicating with the team.
When schedule changes must be made, you ensure they are carried out and communicated according to the
plan laid out in Step 1. Throughout the project, you will ensure that each activity is on schedule and
determine whether corrective action needs to be taken if delays occur.
Project scheduling tools and techniques – 3 main types

There are several project scheduling techniques that can help you break down your project into small,
manageable tasks. Some of these techniques include
Task lists
Gantt charts and
Calendars
1. Task lists
This is the simplest scheduling technique and works for small projects without a lot of interdependencies.
However, for larger projects, it may not be the right choice as tracking the progress can become a major
challenge.
The task list contains the list of tasks and subtasks along with the team members assigned to do them. A
simple project management software can come handy when you’re using task lists.
2. Calendar
The calendar can be used to depict the project timelines of all the tasks throughout the course of the
project. It’s a decent approach to view overlaps between activities. But, this approach suffers from an
inability to assign tasks and view dependencies.
3. Gantt charts
A Gantt chart is the most common tool used by project managers to visualize the timelines and
dependencies in a project. You can get a quick estimate of the time required to complete every task.
The chart shows all the tasks, represented by bars, when they’re set to start and end, how long each task
will last, task dependencies, and where there are overlaps.
Getting the right project scheduling software

It’s important to have the best project management software to help you get organized and stay that way.
With Kissflow Project, you get a digital workspace that’s designed to give you and your team the tools you
need to stay on schedule. Intuitive k a ban boards give everyone a helpful visual of project progress, and
automated alerts keep everyone in the loop on approaching deadlines.
EXPERIMENT 6
Aim:- Use any model for estimating the effort, schedule and
cost of software project.
5 Steps to Software Development Effort Estimation
The software development effort estimation is an essential activity before any software project initiation .
Easily estimate the software effort using known estimation techniques which are Function Points Analysis
( FPA ) and Constructive Cost Model ( COCOMO ) .
What is Estimation and why it is important ?
The estimation is a process to find the most accurate sizing figure for the software project effort , for
example , how many months you will need to develop the software , how many resources you will need to
finish the project in the required time . And this translated to money at the end .
The estimation is important because it gives the project team some confidence about the required effort
and time to plan ahead for the project . Moreover , not all software project is time and material contracts ,
some of them are fixed cost projects and this estimate will be used as a foundation to negotiate the project
cost .
The Estimation Process

As mentioned the estimation is a process and this process contains the following steps to reach the
estimate , this process is cycling until you reach the final estimate for the project .
1- Scoping
You need first to scope the project even if you do not have the full detailed requirements but you can
assume some of them or add margins later . While in most cases you will have a defined scope to start with
. You can always list your assumptions to justify the outcome of the estimation process and its results .
2- Decomposition
In this step , you will need to break your software into smaller components and functions and you can
categorize them to a different set of elements , this is similar to work breakdown structure but only for the
software components not all the working activities for the software . the customer to ensure that You may
also collect different data from the project team you have listed all functionalities .
3- Sizing
In this step , the actual estimation will be done for each component alone , and I will illustrate more about
how you will do that using the techniques mentioned above , this will be illustrated in 8 steps in details
below .
In this step , and for more validation , you can use different estimation techniques to analyze the different
estimation outputs and you may take an average of these estimates as well.
4- Expert and Peer Review After initial estimate , you will need at some point to ask for expert opinion
for some new functionalities you may not aware off , or for considering a review from your peers that you
have done the correct estimation . Moreover , you may need to do some analogy based techniques for
similar components or functions developed before or maybe a similar project to ensure that you are on the
correct path .
5- Estimation Finalization
This can be considered the final step as you aggregate all the estimations from all components and
functions and have a baseline estimate . You can go another round across the process until reaching the
correct estimate which will be approved by the Project team and the Management as well
How to Size
Before we start by describing the 8 sizing steps let us introduce briefly the techniques we will use to size
the project effort .
Function Points Analysis

Function Point Analysis ( FPA ) is a sizing measure of clear business significance . First made public by
Allan Albrecht of IBM in 1979. It depends mainly on estimation the lines of code for the software which is
also considered as a critic for this technique .
FPA can be helpful to estimate the effort for a software project at the early stage when the requirements
are known , but the details of implementation have not yet been specified or evaluated . Which is actually
the most case of the software projects .
To use the FPA , these are the steps to follow after defining the scope and decompose the system
functionality and components.
1. Identify inputs , outputs , file accesses and interfaces external systems

2. Determine the functional complexity of each function
3. Calculate unadjusted FPs by summing weightings
4. Calculate Value Adjustment Factor for the software
5. Apply VAF to UFP to calculate adjusted FPS
Constructive Cost Model ( COCOMO )
The Constructive Cost Model ( COCOMO ) is a procedural software cost estimation model developed by
Barry W. Boehm
Program size is expressed in estimated thousands of source lines of code ( KLOC ) . COCOMO applies to
three classes of software projects :
Organic projects - " small teams with " good " experience working with " less than rigid " requirements ,
Semi - detached projects - " medium " teams with mixed experience working with a mix of rigid and less
than rigid requirements .
Embedded projects - developed within a set of " tight " constraints . It is also a combination of organic
and semi - detached projects . ( hardware , software , operational , ... ) COCOMO is used for estimating the
development effort and time. Let us start
Step 1
We will start with the FPA after we scoped the requirements and decompose the functions , we are ready
to identify the inputs , outputs , file accesses and interfaces to external systems . FPA is measured based on
these below elements :
1. Internal Logical Files ( ILF ) : It is a group of logically related data that is stored and maintained
within the application , for example , databases and files
2. ExternalInterface Files ( EIF ) : is a group of logically related data that will be used by the
application . The difference that these data will not be maintained in the application , for example ,
external databases .
3. External Input ( El ) : It is mainly the data transactions which will be inserted into the
application from outside the application boundary , for example , Data entry process
4. External Output ( EO ) : It is mainly the output of the system functions , for example ,
a transactional data into the database , messages or a report
5. External Inquiry ( EQ ) : It used to present information to a user through the retrieval of data from
ILF or Elf , for example , search queries , or exporting a report
The image below , illustrate the software context based on FPA , and how other users or systems interact
with our software . Now , we will need to list the 5 elements for each subsystem , component , or function
to do the next step.
FPA classifies the complexity of each function type as below

Complexity
Function type Simple ( 5 ) Average ( A ) Complex(c)
Internal Logical File 7 10 15
External Interface File 5 7 10
External Input 3 4 6
External Output 4 5 7
External Inquiry 3 4 6
step 2
The next step is to relate our functions to these complexity levels and apply the weightings for each one ,
for example , let us assume that we have the following outcome from our functional points
Components List Inputs (EI) Outputs (EC) Files(ILF ) Inquiries (EQ) Interfaces(EIF )
Component 1 1 S*3=3 1 S*4=4 2 A*10=20 2 S*3=6 1 C*10=10
2 C*7=14
Component 2 2 A*4=8 3 A*5=15 1 C*15=15 2 A*4=8 2 S*5=10
1 C*6=6
Component 3 3 A*4=12 3 S*4=12 1 S*7=7 - 2 A*7=14
2 C*6=12
As we can see in the table , that we have 3 components and after we applied the weights for each one , we
can see that each one can have more than one input for example , and we can estimate each input weight
according to our judgment of this input complexity . In component 3 we have 3 average inputs and 2
complex input but we do not have any inquiries Step 3:
You can do the same for all the software components or functions and this will lead us to the next step of
calculating the unadjusted function points by summation of all weights.
Unadjusted Function Points ( UFP ) = ( n * EI ) + ( n x EO ) + ( n x EQ ) + ( n * ILF ) + ( n * EIF )
In the example above the UFP = 176
Step 4
The next step , we will need to calculate Value Adjustment Factor , the VAF consists of 14 General
System Characteristics ( GSCs ) which are listed below . These GSCs represent characteristics of the
application under consideration how the degree of influence for each factor on the system .
According to Quantitative Software Management they created a table contains updated function point
language gearing factors for 37 distinct programming languages / technologies . We will use this table to
calculate the KLOC by using this equation
KLines of code ( KLOC ) = AFP QSM Index ( programming language ) / 1000

We assume that we will use .NET programming language , according to OSM table the average of .NET is
57
KLOC = 17657 / 1000 = 10 KLOC Step 7

According to COCOMO Complexity , the software effort is calculated based on predetermined coefficients
based on complexity and , lines of code , for example , if we considered that we are using organic project
type our calculation will be as follow :
Effort Applied ( E ) = a * ( KLOC ) ^ 5 = 3.2 * ( 10 ) 1.05 = 35 Person Months

Development Time ( T ) = c * ( Effort Applied ) ^ d = 2.5 ( 35 ) ^ 0.38 = 9.7 Months
Software Project a b c d
Organic 3.2 105 2.5 0.38
Semi - detached 3 1.12 2.5 0.35
Embedded 2.8 1.20 2.5 0.32
People required ( P ) = Effort Applied / Development Time = 35 / 9.7 = +/- 3.6 Persons
Development Productivity = LOC / Effort Applied = 10,000 / 35 = 286 LOC / Person Month
We have calculated this without calculating the Effort Adjustment Factor ( EAF ) , Intermediate
COCOMO provides 15 attributes rated on a six - point scale that ranges from " very low " to " extra high "
, these 15 attributes called the cost drivers . For each one of them , you can describe how the project is
related to this attribute , for example , Required development schedule which is 10 months we can select a
nominal value for this attribute.
After identifying the weights for all cost drivers , you can multiply all of them to get the EAF . Then , we
can now calculate the adjusted effort according to the below equation :
The adjusted effort applied = a * ( KLOC ) ^ bEAF

If we assume that our EAF is 1.17 then the adjusted effort will equal to 35 1.17 = 41 Person Months .
After that , you can recalculate all the other values again . The first calculation is called the Basic
COCOMO while the second is considered the Intermediate COCOMO .
Step 8
Now , we can apply the cost estimate by calculating the cost of every staffed person * Effort Applied , for
example , if all staff have fixed 2K $ Person Month the cost will be
2,000 * 35 = 70K $
EXPERIMENT 7
Aim: Develop DFD model (level-0,level-1 DFD and Data
dictionary) of the project.
Data Flow Diagram (DFD) of a system represents how input data is converted to output data graphically.
Level 0 also called context level represents most fundamental and abstract view of the system.
Subsequently other lower levels can be decomposed from it. DFD model of a system contains multiple
DFDs but there is a single data dictionary for entire DFD model. Data dictionary comprises definitions of
data items used in DFD.
Context diagram :
It demonstrates entire data flow of a system in a single process/ bubble. Bubble is annotated with ‘Noun’
representing whole system. This is only bubble in DFD where a noun, (in the form of name of a system) is
used. It is named since purpose of context diagram is to grab che context of system and not functionality.
All other bubbles have a verb according to main function performed by it.
Context diagram shows three main things : users, data flow to system and from system. It captures various
external entities interacting with system, data to and from system as incoming and outgoing arrows.
Context diagram requires analysis of SRS document. Data flow is represented with data names on top of
arrow.
Construction of Level 1 and other lower level diagrams :

Level 1 DFD contains 3 to 7 bubbles representing functions. There are processes that can be broken down
into sub – process each representing a bubble. Every Bubble has a verb demonstrating functionality of that
process. To create level1/level 2 or other level DFDs, a bubble is broken into sub-parts containing 3-7
functionalities. If there are more than 7 sub process then some related information can be combines
together. If there are less than 3 sub-process, it can be further decomposed to create more bubbles.
Decomposition :
Bubbles are decomposed into sub functions at successive levels of DFD level.
Decomposition is called exploding/factoring a bubble. Each bubble at any level
can be broken to anything between 3 and 7 bubbles. But a bubble should not be decomposed further once it
is found to represent simple set of instructions. Too many bubbles at any level makes dfd hard to
understand. Very less bubble makes decomposition redundant and trivial.
Numbering :
Each process symbol must utilize a unique reference number to differentiate from one other. When a
bubble x is decomposed, its children are numbered as x.1, x.2 and so on. It can help determine its
ancestors, successors, and precisely its level. For example level 0 DFD is numbered as 0. Level 1 are
numbered as 0.1, 0.2, 0.3 or 1, 2, 3 and so on. Level 2 are marked as 1.1, 1.2, 1.3 etc.
Balancing DFD :
Parent dfd having inflow and out flow of data should match data flow at next child level. This is known as
balancing a DFD. Concept is illustrated in figure :
In Level 1 DFD, data items D1 flow out of bubble 2 and item D2 flows into bubble 2. In next level,
bubble 2 is decomposed into three sub process(2.1, 2.2, 2.3). It has data item D1 flowing out and D2
flowing in. So DFD is balanced here.
A bubble representing a process should have minimum one input and one output flow. When a bubble has
input flow without any output flow, it is known as “black hole”. When a process has output flows but no
input flows, it is called a “miracle”. A processing step may have outputs that are greater than sum of its
inputs is called Grey holes.
Common mistakes to avoid while constructing DFDs :

• DFDs should always represent data flow and there should be no control flow.
• All external entities should be represented at context level.
• All functionality of system must be captured in dfd and none should be overlooked. Also,
only those functions specified in SRS should be represented.
• Arrows connecting to data store need not be annotated with any data name.
• DFDs should always be balanced at all levels. Dataflow in and out of parent process must
be present in child diagram.
• Context level bubble always contains name of entire system in form of noun and no verb can
be used in its representation. Whereas all other levels only have verb in bubble representation.
• There should not be any database in level 0. Level 0 contains only one bubble and external
entities.
• No cluttering should be depicted in DFD. When too may data flowing occurs in and out of DFD,
combine these data item into high level item.
All bubbles having unique process in DFDs should be connected to another process or to a data store. It
cannot exist by itself, unconnected to rest of system.
EXPERIMENT 8
Aim : Develop sequence diagram .
What is a Sequence Diagram?
Sequence diagrams, commonly used by developers, model the interactions between objects in a single use
case. They illustrate how the different parts of a system interact with each other to carry out a function, and
the order in which the interactions occur when a particular use case is executed.
In simpler words, a sequence diagram shows different parts of a system work in a ‘sequence’ to get
something done.
Sequence Diagram Notations

A sequence diagram is structured in such a way that it represents a timeline which begins at the top and
descends gradually to mark the sequence of interactions. Each object has a column and the messages
exchanged between them are represented by arrows.
A Quick Overview of the Various Parts of a Sequence Diagram Lifeline Notation
A sequence diagram is made up of several of these lifeline notations that should be arranged horizontally
across the top of the diagram. No two lifeline notations should overlap each other. They represent the
different objects or parts that int
eract with each other in the system during the sequence.

A lifeline notation with an actor element symbol is used when the particular sequence diagram is owned by
a use case.
A lifeline with an entity element represents system data. For

example, in a customer service application, the Customer entity would manage all data related to a
customer.
A lifeline with a boundary element indicates a system boundary/ software element in a system; for
example, user interface screens, database gateways or menus that users interact with, are boundaries.
And a lifeline with a control element indicates a controlling entity or

manager. It organizes and schedules the interactions between the
boundaries and entities and serves as the mediator between them.
Activation Bars
Activation bar is the box placed on the lifeline. It is used to indicate that an object is active (or
instantiated) during an interaction between two objects. The length of the rectangle indicates the duration
of the objects staying active.
In a sequence diagram, an interaction between two objects occurs when one object sends a message to
another. The use of the activation bar on the lifelines of the Message Caller (the object that sends the
message) and the Message Receiver (the object that receives the message) indicates that both are active/is
instantiated during the exchange of the message.
Message Arrows
An arrow from the Message
Caller to the Message Receiver
specifies a message in a
sequence diagram. A
message can flow in any
direction; from left to right,
right to left or back to the
Message Caller itself. While
you can describe the message
being sent from one object to
the other on the arrow, with
different arrowheads you can
indicate the type of
message being sent or received.

The message arrow comes with a description, which is known as a message signature, on it. The format for
this message signature is below. All parts except the message_name are optional.
attribute = message_name (arguments): return_type
Synchronous message
As shown in the activation bars example, a synchronous message is used when the sender waits for the
receiver to process the message and return before carrying on with another message. The arrowhead used
to indicate this type of message is a solid one, like the one below.
Asynchronous message
An asynchronous message is used when the
message caller does not wait for the receiver to
process the message and return before sending
other messages to other objects within the system.
The arrowhead used to show this type of message is a line arrow like shown in the example below.
Return message
A return message is used to indicate that the message receiver is done processing the message and is
returning control over to the message caller. Return messages are optional notation pieces, for an
activation bar that is triggered by a synchronous message always implies a return message.
Tip: You can avoid cluttering up your diagrams by minimizing the use of return messages since the return
value can be specified in the initial message arrow itself. Return Message Example
Participant creation message

Objects do not necessarily live for the entire duration of the sequence of events.
Objects or participants can be created according to the message that is being sent.
The dropped participant box notation can be used when you need to show that the particular participant did
not exist until the create call was sent. If the created participant does something immediately after its
creation, you should add an activation box right below the participant box.
Participant destruction message

Likewise, participants when no longer needed can also be deleted from a sequence diagram. This is done
by adding an ‘X’ at the end of the lifeline of the said participant.
Reflexive message
When an object sends a message to itself, it is called a reflexive message. It is indicated with a message
arrow that starts and ends at the same lifeline as shown in the example below.
Comment
UML diagrams generally permit the annotation of comments in all UML diagram types. The comment
object is a rectangle with a folded-over corner as shown below. The comment can be linked to the related
object with a dashed line.
EXPERIMENT 9
Aim : Develop structured design for the DFD model
development.
A DFD model of a system graphically depicts the transformation of the data input to the system to the final
result through a hierarchy of levels. A DFD starts with the most abstract definition of the system (lowest
level) and at each higher level DFD, more details are successively introduced. To develop a higher-level
DFD model, processes are decomposed input data to these functions and the data output by these functions
and represent them appropriately in the diagram. If a system has more than 7 high- level functional
requirements, then some of the related requirements have to be combined and represented in the form of a
bubble in the level 1 DFD. Such a bubble can be split in the lower DFD levels. If a system has less than
three high-level functional requirements, then some of them need to be split into their subfunctions so that
we have roughly about 5 to 7 bubbles on the diagram.
Decomposition:- Each bubble in the DFD represents a function performed by the system. The
bubbles are decomposed into sub-functions at the successive levels of the DFD. Decomposition of a bubble
is also known as factoring or exploding a bubble. Each bubble at any level of DFD is usually decomposed
to anything between 3 to 7 bubbles. Too few bubbles at any level make that level superfluous. For
example, if a bubble is decomposed to just one bubble or two bubbles, then this decomposition becomes
redundant. Also, too many bubbles, i.e. more than 7 bubbles at any level of a DFD makes the DFD model
hard to understand. Decomposition of a bubble should be carried on until a level is reached at which the
function of the bubble can be described using a simple algorithm.
Numbering of Bubbles:-
It is necessary to number the different bubbles occurring in the DFD. These numbers help in uniquely
identifying any bubble in the DFD by its bubble number. The bubble at the context level is usually
assigned the number 0 to indicate that it is the 0 level DFD. Bubbles at level 1 are numbered, 0.1, 0.2, 0.3,
etc, etc. When a bubble numbered x is decomposed, its children bubble are numbered x.1, x.2, x.3, etc. In
this numbering scheme, by looking at the number of a bubble we can unambiguously determine its level,
its ancestors, and its successors.
Example:-
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. Each customer who
registers for this scheme is assigned a unique customer number (CN) by the computer.
A customer can present his CN to the checkout 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 C N are the
reset on the day of every year after the prize winners’ lists are generated.
EXPERIMENT 10
Aim: Develop the waterfall model, prototype model and
spiral model of the product.
▪ Waterfall model
Winston Royce introduced the Waterfall Model in 1970.This model has five phases: Requirements analysis
and specification, design, implementation, and unit testing, integration and system testing, and operation
and maintenance. The steps always follow in this order and do not overlap. The developer must complete
every phase before the next phase begins. This model is named "Waterfall Model", because its
diagrammatic representation resembles a cascade of waterfalls.
1. Requirements analysis and specification phase: The aim of this phase is to

understand the exact requirements of the customer and to document them properly. Both the customer
and the software developer work together so as to document all the functions, performance, and
interfacing requirement of the software. It describes the "what" of the system to be produced and not
"how". In this phase, a large document called Software Requirement Specification (SRS) document is
created which contained a detailed description of what the system will do in the common language.
2. Design Phase: This phase aims to transform the requirements gathered in the
SRS into a suitable form which permits further coding in a programming language.
It defines the overall software architecture together with high level and detailed design. All this work is documented
as a Software Design Document (SDD).
3. Implementation and unit testing: During this phase, design is implemented. If the
SDD is complete, the implementation or coding phase proceeds smoothly, because all the information
needed by software developers is contained in the SDD. During testing, the code is thoroughly
examined and modified. Small modules are tested in isolation initially. After that these modules are
tested by writing some overhead code to check the interaction between these modules and the flow of
intermediate output.
4. Integration and System Testing: This phase is highly crucial as the quality of the end
product is determined by the effectiveness of the testing carried out. The better output will lead to
satisfied customers, lower maintenance costs, and accurate results. Unit testing determines the
efficiency of individual modules. However, in this phase, the modules are tested for their interactions
with each other and with the system.
5. Operation and maintenance phase: Maintenance is the task performed by every

user once the software has been delivered to the customer, installed, and operational.
When to use SDLC Waterfall Model?

Some Circumstances where the use of the Waterfall model is most suited are:
• When the requirements are constant and not changed regularly.

• A project is short
• The situation is calm
• Where the tools and technology used is consistent and is not changing
• When resources are well prepared and are available to use.
Advantages of Waterfall model
• This model is simple to implement also the number of resources that are required for it is minimal.
• The requirements are simple and explicitly declared; they remain unchanged during the entire
project development.
• The start and end points for each phase is fixed, which makes it easy to cover progress.
• The release date for the complete product, as well as its final cost, can be determined
before development.
• It gives easy to control and clarity for the customer due to a strict reporting system.
Disadvantages of Waterfall model
• In this model, the risk factor is higher, so this model is not suitable for more significant and
complex projects.
• This model cannot accept the changes in requirements during development.
• It becomes tough to go back to the phase. For example, if the application has now shifted to the
coding phase, and there is a change in requirement, It becomes tough to go back and change it.
• Since the testing done at a later stage, it does not allow identifying the challenges and risks in
the earlier phase, so the risk reduction strategy is difficult to prepare.
Conclusion:
Waterfall is a plan-driven methodology and hence, the whole project strictly follows a clear plan, which
requires extensive planning upfront. That allows an estimation of costs and timeline which can be
discussed with the customer in advance. The existence of an elaborated plan and clear documentation also
results in a more secure project as everyone exactly knows what to do and new members can easily join the
team.
• Prototyping Model
What is Prototyping Model?

Prototyping Model is a software development model in which prototype is built, tested, and reworked until
an acceptable prototype is achieved. It also creates base to produce the final system or software. It works
best in scenarios where the project's requirements are not known in detail. It is an iterative, trial and error
method which takes place between developer and client.
Prototyping Model has following six SDLC phases as follow:
Step 1: Requirements gathering and analysis

A prototyping model starts with requirement analysis. In this phase, the requirements of the system are
defined in detail. During the process, the users of the system are interviewed to know what is their
expectation from the system.
Step 2: Quick design

The second phase is a preliminary design or a quick design. In this stage, a simple design of the system is
created. However, it is not a complete design. It gives a brief idea of the system to the user. The quick
design helps in developing the prototype.
Step 3: Build a Prototype
In this phase, an actual prototype is designed based on the information gathered from quick design. It is
a small working model of the required system.
Step 4: Initial user evaluation

In this stage, the proposed system is presented to the client for an initial evaluation. It helps to find out the
strength and weakness of the working model. Comment and suggestion are collected from the customer
and provided to the developer.
Step 5: Refining prototype

If the user is not happy with the current prototype, you need to refine the prototype according to the user's
feedback and suggestions.
This phase will not over until all the requirements specified by the user are met. Once the user is satisfied
with the developed prototype, a final system is developed based on the approved final prototype.
Step 6: Implement Product and Maintain

Once the final system is developed based on the final prototype, it is thoroughly tested and deployed to
production. The system undergoes routine maintenance for minimizing downtime and prevent large-scale
failures.
Types of Prototyping Models

Four types of Prototyping models are:
1. Rapid Throwaway prototypes

2. Evolutionary prototype
3. Incremental prototype
4. Extreme prototype
Rapid Throwaway Prototype

Rapid throwaway is based on the preliminary requirement. It is quickly developed to show how the
requirement will look visually. The customer's feedback helps drives changes to the requirement, and the
prototype is again created until the requirement is base lined.
In this method, a developed prototype will be discarded and will not be a part of the ultimately accepted
prototype. This technique is useful for exploring ideas and getting instant feedback for customer
requirements.
Evolutionary Prototyping
Here, the prototype developed is incrementally refined based on customer's feedback until it is finally
accepted. It helps you to save time as well as effort. That's because developing a prototype from scratch for
every interaction of the process can sometimes be very frustrating.
This model is helpful for a project which uses a new technology that is not well understood. It is also used
for a complex project where every functionality must be checked once. It is helpful when the requirement
is not stable or not understood clearly at the initial stage.
Incremental Prototyping
In incremental Prototyping, the final product is decimated into different small prototypes and developed
individually. Eventually, the different prototypes are merged into a single product. This method is helpful
to reduce the feedback time between the user and the application development team.
Extreme Prototyping
Extreme prototyping method is mostly used for web development. It is consists of three sequential phases.
• Basic prototype with the entire existing page is present in the HTML format.
• You can simulate data process using a prototype services layer.
• The services are implemented and integrated into the final prototype.
Advantages of the Prototyping Model

Here, are important pros/benefits of using Prototyping models:
• Users are actively involved in development. Therefore, errors can be detected in the initial stage of
the software development process.
• Missing functionality can be identified, which helps to reduce the risk of failure as Prototyping is
also considered as a risk reduction activity.
• Helps team member to communicate effectively
• Customer satisfaction exists because the customer can feel the product at a very early stage.
• There will be hardly any chance of software rejection.
• Quicker user feedback helps you to achieve better software development solutions.
• Allows the client to compare if the software code matches the software specification.
• It helps you to find out the missing functionality in the system.
• It also identifies the complex or difficult functions.
• Encourages innovation and flexible designing.
• It is a straightforward model, so it is easy to understand.
• No need for specialized experts to build the model
• The prototype serves as a basis for deriving a system specification.
• The prototype helps to gain a better understanding of the customer's needs.
• Prototypes can be changed and even discarded.
• A prototype also serves as the basis for operational specifications.
• Prototypes may offer early training for future users of the software system.
A
Disadvantages of the Prototyping Model

Here, are important cons/drawbacks of prototyping model:
• Prototyping is a slow and time taking process.

• The cost of developing a prototype is a total waste as the prototype is ultimately thrown away.
• Prototyping may encourage excessive change requests.
• Sometimes customers may not be willing to participate in the iteration cycle for the longer time
duration.
• There may be far too many variations in software requirements when each time the prototype is
evaluated by the customer.
• Poor documentation because the requirements of the customers are changing.
• It is very difficult for software developers to accommodate all the changes demanded by the
clients.
• After seeing an early prototype model, the customers may think that the actual product will
be delivered to him soon.
• The client may lose interest in the final product when he or she is not happy with the initial
prototype.
• Developers who want to build prototypes quickly may end up building substandard development
solutions.
Conclusion:
The prototype model is a trial and error method which has its advantages and disadvantages. It is
particularly useful when the client does not have clarity on what all features, they need in the product.
Spiral model
The spiral model, initially proposed by Boehm, is an evolutionary software process model that couples the
iterative feature of prototyping with the controlled and systematic aspects of the linear sequential model. It
implements the potential for rapid development of new versions of the software. Using the spiral model,
the software is developed in a series of incremental releases. During the early iterations, the additional
release may be a paper model or prototype. During later iterations, more and more complete versions of the
engineered system are produced.
The Spiral Model is shown in fig:
Each cycle in the spiral is divided into four parts:
• Objective setting: Each cycle in the spiral starts with the identification of purpose for that cycle,
the various alternatives that are possible for achieving the targets, and the constraints that exists.
• Risk Assessment and reduction: The next phase in the cycle is to calculate these various
alternatives based on the goals and constraints. The focus of evaluation in this stage is located
on the risk perception for the project.
• Development and validation: The next phase is to develop strategies that resolve uncertainties
and risks. This process may include activities such as benchmarking, simulation, and prototyping.
• Planning: Finally, the next step is planned. The project is reviewed, and a choice made whether to
continue with a further period of the spiral. If it is determined to keep, plans are drawn up for the
next step of the project. The development phase depends on the remaining risks.
For example, if performance or user-interface risks are treated more essential than the program
development risks, the next phase may be an evolutionary development that includes developing a more
detailed prototype for solving the risks.
The risk-driven feature of the spiral model allows it to accommodate any mixture of a specification-
oriented, prototype-oriented, simulation-oriented, or another type of approach. An essential element of the
model is that each period of the spiral is completed by a review that includes all the products developed
during that cycle, including plans for the next cycle. The spiral model works for development as well as
enhancement projects.
When to use Spiral Model?

• When deliverance is required to be frequent.
• When the project is large
• When requirements are unclear and complex
• When changes may require at any time
• Large and high budget projects
Advantages
• High amount of risk analysis

• Useful for large and mission-critical projects.
Disadvantages
• Can be a costly model to use.

• Risk analysis needed highly particular expertise • Doesn't work well for smaller
projects.
Conclusion:
Each spiral can be termed as a loop and each loop is a separate development process in a spiral model. The
four activities (Planning, Risk analysis, engineering and evaluation) form the intermediary phases of a
spiral model and is repeated again for each loop.
EXPERIMENT 11
Aim: Explain with reason which model is best suited for the
product.
Prototyping Model
The Prototyping Model is one of the most popularly used Software Development Life Cycle Models
(SDLC models).This model is used when the customers do not know the exact project requirements
beforehand. In this model, a prototype of the end product is first developed, tested and refined as per
customer feedback repeatedly till a final acceptable prototype is achieved which forms the basis for
developing the final product.
In this process model, the system is partially implemented before or during the analysis phase thereby
giving the customers an opportunity to see the product early in the life cycle. The process starts by
interviewing the customers and developing the incomplete high-level paper model. This document is used
to build the initial prototype supporting only the basic functionality as desired by the customer. Once the
customer figures out the problems, the prototype is further refined to eliminate them. The process
continues until the user approves the prototype and finds the working model to be satisfactory.
There are four types of model available:
A) Rapid Throwaway Prototyping –

This technique offers a useful method of exploring ideas and getting customer feedback for each of them.
In this method, a developed prototype need not necessarily be a part of the ultimately accepted prototype.
Customer feedback helps in preventing unnecessary design faults and hence, the final prototype developed
is of better quality.
B) Evolutionary Prototyping –
In this method, the prototype developed initially is incrementally refined on the basis of customer feedback
till it finally gets accepted. In comparison to Rapid Throwaway Prototyping, it offers a better approach
which saves time as well as effort. This is because developing a prototype from scratch for every iteration
of the process can sometimes be very frustrating for the developers.
C) Incremental Prototyping – In this type of incremental Prototyping, the final expected product
is broken into different small pieces of prototypes and being developed individually. In the end, when all
individual pieces are properly developed, then the different prototypes are collectively merged into a
single final product in their predefined order. It’s a very efficient approach which reduces the complexity
of the development process, where the goal is divided into sub-parts and each sub-part is developed
individually. The time interval between the project begin and final delivery is substantially reduced
because all parts of the system are prototyped and tested simultaneously. Of course, there might be the
possibility that the pieces just not fit together due to some lack ness in the development phase – this can
only be fixed by careful and complete plotting of the entire system before prototyping starts.
D) Extreme Prototyping – This method is mainly used for web development. It is consists of
three sequential independent phases:
D.1) In this phase a basic prototype with all the existing static pages are presented in the HTML
format.
D.2) In the 2nd phase, Functional screens are made with a simulate data process using a
prototype services layer.
D.3) This is the final step where all the services are implemented and associated with the final
prototype.
This Extreme Prototyping method makes the project cycling and delivery robust and fast, and keeps the
entire developer team focus centralized on products deliveries rather than discovering all possible needs
and specifications and adding unnecessitated features.
Advantages –
• The customers get to see the partial product early in the life cycle. This ensures a greater level of
customer satisfaction and comfort.
• New requirements can be easily accommodated as there is scope for refinement.
• Missing functionalities can be easily figured out.
• Errors can be detected much earlier thereby saving a lot of effort and cost, besides enhancing
the quality of the software.
• The developed prototype can be reused by the developer for more complicated projects in
the future.
• Flexibility in design.
Disadvantages –
• Costly w.r.t time as well as money.
• There may be too much variation in requirements each time the prototype is evaluated by the
customer.
• Poor Documentation due to continuously changing customer requirements.
• It is very difficult for developers to accommodate all the changes demanded by the customer.
• There is uncertainty in determining the number of iterations that would be required before
the prototype is finally accepted by the customer.
• After seeing an early prototype, the customers sometimes demand the actual product to be
delivered soon.
• Developers in a hurry to build prototypes may end up with sub-optimal solutions.
• The customer might lose interest in the product if he/she is not satisfied with the initial prototype .
Use –
The Prototyping Model should be used when the requirements of the product are not clearly understood or
are unstable. It can also be used if requirements are changing quickly. This model can be successfully used
for developing user interfaces, high technology software-intensive systems, and systems with complex
algorithms and interfaces. It is also a very good choice to demonstrate the technical feasibility of the
product.
EXPERIMENT 12
Aim: Develop a working protocol of any of two problem.
How to Develop a Protocol or Procedures
Protocols and procedures are the specific way that a policy, rule or principle is carried out. It can often be
thought of as a set of instructions. Procedures can help small businesses to function productively by
ensuring that everyone executes tasks in the same way. It can be beneficial for organizations to review
their protocols and procedures on an ensure that they are up to date and reflect current business objectives.
Developing protocols and procedures is a matter of understanding the company's direction and goals.
1. Identify the policy or rule that needs a procedure attached to it. Clearly understand the goal of the
policy, such as if it is solving a problem, increasing productivity, ensuring quality of a product or service,
or if it is preventing a potential conflict. Consider similar protocols that have been put in place in the past
and determine if they can be used as models for this particular issue.
2. Determine if your management or staff needs to acquire any additional skills or equipment to
complete the procedure. For example, the procedure may involve scanning documents for electronic files
so that you are able to do away with paper files. Therefore you may need to purchase a scanner and then
train particular staff members on its operation methods. Additionally, you may need a companywide
document distributed explaining how employees are now able to access the electronic files.
3. Document the procedure in a step-by-step format. Make sure the instructions are clear and easily
understood by the various people who will need to follow the protocol. Use layman's terms whenever
possible to eliminate any potential confusion.
4. Test the protocol out. Distribute the instructions to a test group of three to five people and have
them put the procedure through a trial run. Ask them to document any problems that they encounter while
executing the protocol. Have them make suggestions on ways to improve the instructions or methods.
4 Review the test group's findings and notice any problems or challenges with the procedure. For example,
the test group may have noticed that gridlock will be created if your company purchases only one
scanner since numerous people will be using it. Amend the protocol as necessary.
6. Finalize the protocol and submit it to management for approval. Gather feedback from your
supervisors and make any needed changes.
7. Create a clean final document that outlines the protocol. Distribute the document to the staff, or to
the particular people whom it affects. Follow up with the employees to make sure that the instructions are
understandable.
Keys to a Successful Rollout of New Procedures

Companies often have to roll out new procedures as a response to new technologies or changing business
conditions. The procedures could be for negotiating procurement contracts, using company property,
recruiting new candidates or carrying out other functions. Treat the rollout of these new procedures as you
would any other change initiative. Successful change management requires planning, communication,
training and monitoring.
Planning
Change management planning usually involves preparing a schedule and a budget. For example, if you are
rolling out new quality control procedures for your small business, prepare a schedule for the software
implementation and the training and a budget for the related costs. Your budget should factor in the lost
productivity of employees affected by the transition from the old to the new procedures. Consider doing
the rollout in stages if you are managing the process for a medium or large business. For example, you
could implement the procedures in a small department, resolve any implementation issues and then roll
them out to other departments.
Communication
Successful change implementation requires a good communication strategy, which starts with an
explanation of the rationale for the new procedures. You should expect some resistance to change. Talk to
the most vocal resisters in one-on-one settings and listen to their concerns because some of them may have
constructive ideas on how to increase the chances of success in implementing these new procedures. Some
of the resistance may be due to bad experiences with prior procedural changes. Explain how these new
procedures can bridge the gap between the old way of doing things today to deal with changing business
realities, suggests MIT lecturer Jonathan Byrnes in a July 2005 Harvard Business School Working
Knowledge article.
Training
New procedures mean a new way of doing things. To minimize confusion and errors, train your employees
in the new procedures. The training documents should include description of the new procedures and
instructions on how to transition from the old procedures. If you are managing the rollout in a large
company, train the key business unit managers, who can then train their team members. The training could
also help mobilize support in the organization, suggests Harvard professor Michael A. Roberto and
researcher Lynne
C. Levesque in School Working Knowledge article.
Monitoring
Monitor how employees are using the new procedures and adjust them if necessary. Monitoring may
involve comparing financial and quality metrics before and after the rollout of the new procedures. It may
also involve actively soliciting feedback from employees and other affected stakeholders on how you could
improve these procedures.
Experiment 13
Aim:- Use LOC, FP and Cyclamate Complexity Metric of
above-mentioned problem
Use of LOC
LINES OF CODE
Lines of code (LOC) specifically include all lines containing program headers,
declarations, and executable and non-executable codes in a software program. Source
LOC (SLOC) are software metrics that are used to measure the size of a software
program by just counting the number of lines in the source code of the program. SLOC
are used to predict (approximate) the efforts required to write the code and are also used
to estimate the maintainability hours after the code is written.
Types of SLOC Measures
Refer that depicts the following SLOC types:
1. Physical SLOC (PLOC)

2. Logical SLOC (LLOC)
3. Comment SLOC (CLOC)
4. Reused SLOC (RLOC)
PLOC is a count of lines in the text of the physical source code including comment lines,
declarations, and blank lines.
Specialized SLOC Metrics
LLOC is a count of lines of only the executable “statements.” Lines of the comments,
declarations, and blank lines are not counted for this purpose. This definition varies with
computer language because the meaning of the “executable statements” varies across
computer language. LLOC is a widely used concept for various LOC estimations.
CLOC is a count of lines consisting of only the comments in the source code. Codes
written without any comments are considered as poor code. Good codes tend to
have appropriate comments.
RLOC is the count of lines reused in the particular code, which will not be counted for
calculating the efforts. People encouraged writing and using the reusable code, which
saves lot of efforts during the development process.
POINTS TO PONDER
PLOC is a count of lines in the text of the physical source code including comment lines,
declarations, and blank lines. LLOC is a count of lines of the only executable
“statements”. Lines of the comments, declarations, and blank lines are not counted for
this purpose.
Let us see an example (C program):
1. /* Beginning of the for loop */

2. for ( i= 50; i< 0; i − = 1)
3. {
4. printf(“Hai Students”);
5. }
6. /* End of the for loop */
Physical SLOC is represented by PLOC.
LLOC is represented by LLOC.
Comment SLOC is represented by CLOC.
How many total LOC are there in the above program?
How many executable LOC are there in the above
program? How many comments LOC are there in the above
program? PLOC = 6 (totally there are six lines – Lines 1–6)
LLOC = 2 (totally there are two executable lines – Lines 2 and
4) CLOC = 2 (totally there are two comments line – Lines 1 and
6)
FORTRAN and Assembler are line-oriented languages in which the LOC concepts are
used effectively.
Various widely used LOC measurements along with meaning are given in Table 10.1.
LOC Measurement and Meanings
Measurement Meaning
KLOC 1000 Lines Of Code
KDLOC 1000 Delivered Lines Of Code
KSLOC 1000 Source Lines Of Code
MLOC 1,000,000,000 Lines Of Code
Advantages of the Line of Code Measure
1. Easy to learn
2. Easy to measure (scope of automated counting)
3. Easy to report and check
4. Complex formulas not used
5. Repeatability is possible
6. Measurement easily automatable
Since it is easy to calculate, easy to measure and easy to report (refer Figure 10.2), even
junior people can use LOC for estimation purposes.
Drawbacks of the Line of Code Measure
1. There is no standard definition of what is LOC – There are different versions

of measurement.
2. Functionality of the code not taken into consideration for the calculation. This
is the big drawback of LOC.
3. Skilled coders can develop the same code with less lines (as per LOC, they
are considered as less productive, which is not correct).
4. Developer who produce more lines does not mean productive.
5. Complexity of the code is not taken into the consideration (complex code may
be written in few lines but may take longer time to code).
6. LOC is non-comparable across languages (Java program LOC is not
comparable with C language LOC).
7. Estimates based on LOC can adversely go wrong because LOC is not a
direct measure of functionality or productivity.
8. If LOC is used for measurements, people may add junk code j to increase LOC
which may not add any value to anybody.
9. Low utility as sizing measure.
Constructive cost model (COCOMO) and other series of models by Barry Boehm et al.
use SLOC as an input parameter. We will be discussing this model (COCOMO) in detail
in the later part of this chapter.
LOC should not be used to measure the software productivity.
“Measuring software productivity by lines of code is like measuring progress on an airplane

by how much it weights.”
Functional Point (FP)

Allan J. Albrecht initially developed function Point Analysis in 1979 at IBM and it has been
further modified by the International Function Point Users Group (IFPUG). FPA is used to make
estimate of the software project, including its testing in terms of functionality or function size of
the software product. However, functional point analysis may be used for the test estimation of
the product. The functional size of the product is measured in terms of the function point, which is
a standard of measurement to measure the software application.
759
Objectives of FPA
The basic and primary purpose of the functional point analysis is to measure and provide the
software application functional size to the client, customer, and the stakeholder on their request.
Further, it is used to measure the software project development along with its maintenance,
consistently throughout the project irrespective of the tools and the technologies.
Following are the points regarding FPs
1. FPs of an application is found out by counting the number and types of functions used in the
applications. Various functions used in an application can be put under five types, as shown in
Table:
Types of FP Attributes
Measurements Parameters Examples
1.Number of External Inputs(EI) Input screen and tables
2. Number of External Output (EO) Output screens and reports
3. Number of external inquiries (EQ) Prompts and interrupts.
4. Number of internal files (ILF) Databases and directories
5. Number of external interfaces (EIF) Shared databases and shared routines.
All these parameters are then individually assessed for complexity.
The FPA functional units are shown in Fig:

2. FP characterizes the complexity of the software system and hence can be used to depict the
project time and the manpower requirement.
3. The effort required to develop the project depends on what the software does.
4. FP is programming language independent.
5. FP method is used for data processing systems, business systems like information systems.
6. The five parameters mentioned above are also known as information domain characteristics
7. All the parameters mentioned above are assigned some weights that have been experimentally
determined and are shown in Table
Weights of 5-FP Attributes
Measurement Parameter Low Average High
1. Number of external inputs (EI) 7 10 15
2. Number of external outputs (EO) 5 7 10
3. Number of external inquiries (EQ) 3 4 6
4. Number of internal files (ILF) 4 5 7
5. Number of external interfaces (EIF) 3 4 6
The functional complexities are multiplied with the corresponding weights against each function,
and the values are added up to determine the UFP (Unadjusted Function Point) of the subsystem.
Here that weighing factor will be simple, average, or complex for a measurement parameter type.
The Function Point (FP) is thus calculated with the following formula.
FP = Count-total * [0.65 + 0.01 * ∑(fi)]

= Count-total * CAF
where Count-total is obtained from the above Table.
CAF = [0.65 + 0.01 *∑(fi)]
and ∑(fi) is the sum of all 14 questionnaires and show the complexity adjustment value/ factor-
CAF (where i ranges from 1 to 14). Usually, a student is provided with the value of ∑(fi)
Also note that ∑(fi) ranges from 0 to 70, i.e.,
0 <= ∑(fi) <=70
and CAF ranges from 0.65 to 1.35 because
a. When ∑(fi) = 0 then CAF = 0.65

b. When ∑(fi) = 70 then CAF = 0.65 + (0.01 * 70) = 0.65 + 0.7 = 1.35
Based on the FP measure of software many other metrics can be computed:
1. Errors/FP
2. $/FP.
3. Defects/FP
4. Pages of documentation/FP
5. Errors/PM.
6. Productivity = FP/PM (effort is measured in person-months).
7. $/Page of Documentation.
8. LOCs of an application can be estimated from FPs. That is, they are interconvertible. This
process is known as backfiring. For example, 1 FP is equal to about 100 lines of COBOL code.
9. FP metrics is used mostly for measuring the size of Management Information System (MIS)
software.
10. But the function points obtained above are unadjusted function points (UFPs). These (UFPs)
of a subsystem are further adjusted by considering some more General System Characteristics
(GSCs). It is a set of 14 GSCs that need to be considered. The procedure for adjusting UFPs is as
follows:
a. Degree of Influence (DI) for each of these 14 GSCs is assessed on a scale of 0 to 5. (b) If a
particular GSC has no influence, then its weight is taken as 0 and if it has a strong influence then its weight
is 5.
b. The score of all 14 GSCs is totaled to determine Total Degree of Influence (TDI).
c. Then Value Adjustment Factor (VAF) is computed from TDI by using the formula: VAF = (TDI *
0.01) + 0.65
Remember that the value of VAF lies within 0.65 to 1.35 because
a. When TDI = 0, VAF = 0.65

b. When TDI = 70, VAF = 1.35
c. VAF is then multiplied with the UFP to get the final FP count: FP = VAF * UFP
Example: Compute the function point, productivity, documentation, cost per function for the
following data:
1. Number of user inputs = 24

2. Number of user outputs = 46
3. Number of inquiries = 8
4. Number of files = 4
5. Number of external interfaces = 2

6. Effort = 36.9 p-m
7. Technical documents = 265 pages
User documents = 122 pages
1.
2. Cost = $7744/ month
Various processing complexity factors are: 4, 1, 0, 3, 3, 5, 4, 4, 3, 3, 2, 2, 4, 5.
Solution:
Measurement Parameter Count Weighing

factor
1. Number of external inputs (EI) 24 * 4 = 96
2. Number of external outputs (EO) 46 * 4 = 184
3. Number of external inquiries (EQ) 8 * 6 = 48
4. Number of internal files (ILF) 4 * 10 = 40
5. Number of external interfaces (EIF) Count-total → 2 * 5 = 10

378
So sum of all fi (i ← 1 to 14) = 4 + 1 + 0 + 3 + 5 + 4 + 4 + 3 + 3 + 2 + 2 + 4 + 5 = 43

FP = Count-total * [0.65 + 0.01 *∑(fi)]
= 378 * [0.65 + 0.01 * 43]

= 378 * [0.65 + 0.43]
= 378 * 1.08 = 408
Total pages of documentation = technical document + user document

= 265 + 122 = 387pages
Documentation = Pages of documentation/FP

= 387/408 = 0.94
Cyclomatic Complexity
Cyclomatic complexity of a code section is the quantitative measure of the number of

linearly independent paths in it. It is a software metric used to indicate the complexity of
a program. It is computed using the Control Flow Graph of the program. The nodes in
the graph indicate the smallest group of commands of a program, and a directed edge in
it connects the two nodes i.e. if second command might immediately follow the first
command.
For example, if source code contains no control flow statement then its cyclomatic
complexity will be 1 and source code contains a single path in it. Similarly, if the source
code contains one if condition then cyclomatic complexity will be 2 because there will
be two paths one for true and the other for false.
Mathematically, for a structured program, the directed graph inside control flow is the
edge joining two basic blocks of the program as control may pass from first to second.
So, cyclomatic complexity M would be defined as,
M = E – N + 2P
where,
E = the number of edges in the control flow graph
N = the number of nodes in the control flow graph
P = the number of connected components
Steps that should be followed in calculating cyclomatic complexity and test cases design
are:
 Construction of graph with nodes and edges from code.

 Identification of independent paths.
 Cyclomatic Complexity Calculation
 Design of Test Cases
Let a section of code as such:
A = 10
IF B > C THEN A =
B
ELSE
A=C
ENDIF
Print A
Print B
Print C
Control Flow Graph of above code

The cyclomatic complexity calculated for above code will be from control flow graph.
The graph shows seven shapes(nodes), seven lines(edges), hence cyclomatic complexity
is 7-7+2 = 2.
Use of Cyclomatic Complexity:
 Determining the independent path executions thus proven to be very helpful for
Developers and Testers.
 It can make sure that every path have been tested at least once.
 Thus help to focus more on uncovered paths.
 Code coverage can be improved.
 Risk associated with program can be evaluated.
 These metrics being used earlier in the program helps in reducing the risks.
Advantages of Cyclomatic Complexity:.
 It can be used as a quality metric, gives relative complexity of various designs.
 It is able to compute faster than the Halstead’s metrics.
 It is used to measure the minimum effort and best areas of concentration for testing.
 It is able to guide the testing process.
 It is easy to apply.
Disadvantages of Cyclomatic Complexity:
 It is the measure of the programs’s control complexity and not the data the data
complexity.
 In this, nested conditional structures are harder to understand than non-nested
structures.
 In case of simple comparisons and decision structures, it may give a misleading
figure.
Experiment 14
Aim:- Find Maintainability Index and Reusability Index of
above-mentioned problem
Maintainability Index
Maintainability Index is a software metric which measures how maintainable (easy to support and
change) the source code is. The maintainability index is calculated as a factored formula
consisting of SLOC (Source Lines Of Code), Cyclomatic Complexity and Halstead volume. It is
used in several automated software metric tools, including the Microsoft Visual Studio 2010
development environment, which uses a shifted scale (0 to 100) derivative.
Common formulas are:
Where:
 Vis the Halstead Volume (see below);

 is the total Cyclomatic Complexity;
 L is the number of Source Lines of Code (SLOC);
 C is the percent of comment lines (important: converted to radians).
Reusability Index
In computer science and software engineering, reusability is the use of existing assets in some form
within the software product development process; these assets are products and by-products of the
software development life cycle and include code, software components, test suites, designs and
documentation. The opposite concept of reusability is leverage, which modifies existing assets as needed
to meet specific system requirements. Because reuse implies the creation of a separately
version of the assets[clarification needed], it is preferred over leverage.[1]
Subroutines or functions are the simplest form of reuse. A chunk of code is regularly organized
using modules or namespaces into layers. Proponents claim that objects and software components offer a
more advanced form of reusability, although it has been tough to objectively measure and define levels or
scores of reusability.
The ability to reuse relies in an essential way on the ability to build larger things from smaller parts, and
being able to identify commonalities among those parts. Reusability is often a required characteristic
of platform software. Reusability brings several aspects to software development that do not need to be
considered when reusability is not required.
Reusability implies some explicit management
of build, packaging, distribution, installation, configuration, deployment, maintenance and upgrade issues.
If these issues are not considered, software may appear to be reusable from design point of view, but will
not be reused in practice.
Code rule
Code reuse, also called software reuse, is the use of existing software, or software knowledge, to
build new software,[1][2]: 7 following the reusability principles.
Code reuse may be achieved by different ways depending on a complexity of a
programming language chosen and range from a lower-level approaches like code copy-
pasting (e.g.
via snippets),[3] simple functions (procedures or subroutines) or a bunch of objects or functions
organized into modules (e.g. libraries)[4][2]: 7 or custom namespaces,
and packages, frameworks or software suites in higher-levels.
Types of reuse
Concerning motivation and driving factors, reuse can be:
 Opportunistic – While getting ready to begin a project, the team realizes that there are existing components
that they can reuse.
 Planned – A team strategically designs components so that they'll be reusable in future
projects. Reuse can be categorized further:
 Internal reuse – A team reuses its own components. This may be a business decision, since the team may
want to control a component critical to the project.
 External reuse – A team may choose to license a third-party component. Licensing a third-party component
typically costs the team 1 to 20 percent of what it would cost to develop
 internally.[8] The team must also consider the time it takes to find, learn and integrate the component.
Concerning form or structure of reuse, code can be:[9]
 Referenced – The client code contains a reference to reused code, and thus they have distinct life
cycles and can have distinct versions.
 Forked – The client code contains a local or private copy of the reused code, and thus they share a
single life cycle and a single version.
Example:-
Software libraries
A very common example of code reuse is the technique of using a software library. Many
common operations, such as converting information among different well-known formats,
accessing external storage, interfacing with external programs, or manipulating information
(numbers, words, names, locations, dates, etc.) in common ways, are needed by many different
programs. Authors of new programs can use the code in a software library to perform these tasks,
instead of "re-inventing the wheel", by writing fully new code directly in a program to perform an
operation. Library implementations often have the benefit of being well-tested and covering
unusual or arcane cases. Disadvantages include the inability to tweak details which may affect
performance or the desired output, and the time and cost of acquiring, learning, and configuring
the library.[11
Experiment 15
Aim:- Using any Case Tool find number of statements, depth and
complexity of the prototype
It's no secret code is a complicated thing to write, debug, and maintain which is
necessary for high software quality. Moreover, high code complexity brings with
it a higher level of code defects, making the code costlier to maintain.
So, by reducing code complexity, we can reduce the number of bugs and defects,
along with its lifetime cost. What exactly is complex code? How can we
objectively assess how complex a piece of code is, whether that's an entire
codebase or one small function?
In this article, I'm going to walk through three complexity metrics for assessing
code complexity. These are:
 Cyclomatic complexity
 Switch statement and logic condition complexity
 Developer skill
I'll also go through some of the benefits of assessing and understanding code
complexity.
Cyclomatic Complexity
In 1976, Thomas McCabe Snr proposed a metric for calculating code
complexity, called Cyclomatic Complexity. It's defined as:
In 1976, Thomas McCabe Snr proposed a metric for calculating code

complexity, called Cyclomatic Complexity. It's defined as:
A quantitative measure of the number of linearly independent paths through a
program's source code...computed using the control flow graph of the
program.
If you're not familiar with a Control Flow Graph:
It is a representation, using graph notation, of all paths that might be traversed
through a program during its execution.
Said more straightforwardly, the fewer the paths through a piece of code, and the
less complex those paths are, the lower the Cyclomatic Complexity. As a result,
the code is less complicated. To demonstrate the metric, let's use three,
somewhat arbitrary, Go code examples.
Example One
1 func main() {
2 fmt.Println("1 + 1 =", 1+1)
3 }
As there's only one path through the function, it has a Cyclomatic Complexity
score of 1, which we can find by running gocyclo on it.
Example Two
1 func main() {
2 year, month, day := time.Now().Date()

3 if month == time.November && day == 10 && year == 2018 {
4 fmt.Println("Happy Go day!")
5 }
else {
6 fmt.Println("The current month is", month)
}
}
In this example, we're retrieving the current year, month, and day. With this
information, we then check if the current date is the 10th of November 2018
with an if/else condition.
If it is, then the code prints "Happy Go day!" to the console. If it isn't, then it
prints "The current month is" and the name of the current month. The code
example is made more complicated if the condition is composed of three sub-
conditions. Given that, it has a higher complexity score of 4.
Example Three
1
2
func main() {
3
_, month, _ := time.Now().Date()
4
5
switch month {
6
case time.January:
7
fmt.Println("The current month is January.")
case time.February: 8
fmt.Println("The current month is February.")9
10
case time.March:
11
fmt.Println("The current month is March.")
12
case time.April:
13
fmt.Println("The current month is April.")
case time.May:
14
15
fmt.Println("The current month is May.")
16
default:
17
fmt.Println("The current month is unknown.")
18
}
}
Switch Statement and Logic Condition Complexity
The next assessor of code complexity is the switch statement and logic condition complexity.
In the code example below, I've taken the second Go example and split the compound if
condition into three nested conditions; one for each of the original conditions.
1
2
func main() {
3
year, month, day := time.Now().Date()
4
output := fmt.Sprintf("The current month is %s", month)
5
6
if month == time.November {
7
if day == 13 {
8
if year == 2018 {
9
output = fmt.Sprintf("Happy Go day!")
}
10
11
}
12
}
13
14
fmt.Println(output)
}
The Benefits of Measuring Software Complexity
There are four core benefits of measuring code complexity, plus one extra.
Better Tests
By knowing how many independent paths there are through a piece of code, we know how
many paths there are to test.
I'm not advocating for 100% code coverage by the way—that's often a meaningless software
metric. However, I always advocate for as high a level of code coverage as is both practical
and possible.
So, by knowing how many code paths there are, we can know how many paths we have to test.
As a result, you have a measure of how many tests are required, at a minimum, to ensure that the
code's covered.
Jhanjeri, Mohali-
Department of Computer

Software Engg Lab Manual

Uploaded by

Copyright:

Available Formats

Software Engg Lab Manual

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Engg Lab Manual

Uploaded by

Copyright:

Available Formats

Chandigarh School of Business Jhanjeri, Mohali-140307

Department of Computer Applications

Check-list for Lab Course

Sr. No. Contents Yes/No

10. Continuous Evaluation ( Lab Evaluation Sheets)

Prepared by: Checked by: Approved by

VISION & MISSION

Institute Vision and Mission

 Inculcate ethical and moral values in students.

Department Vision and Mission

PROGRAMME OUTCOMES (POs)

Computer Science & Engineering Graduates will be able to:

PO1: Engineering knowledge: Apply the knowledge of mathematics, science, engineering

PO10: Communication: Communicate effectively on complex engineering activities with the

Lab Course Syllabus

Faculty Sign HOD Sign

Course Data Sheet

COURSE DATA SHEET

Course Outcomes: Students will be able to

CO# Course outcomes

1. Identify project scope and objective of given problem:

2. Develop software requirements specification for (1 a.) and (1 b.) problem.

12. Develop a working protocol of any of two problem

13. Use LOC, FP and Cyclomatic Complexity Metric of above-mentioned problem

14. Find Maintainability Index and Reusability Index of above-mentioned problem

1. Software Engineering–A Practitioner’s Approach, Roger S.Pressman, SeventhEdition,

C.CODE COURSE DESCRIPTION SEM

CO2 Analyze and translate a specification into a design PO(2,3,10)

CO3 Realize design practically, using an appropriate software PO(1,2,3,6)

CO5 Use modern engineering tools for specification, design, PO(1,3,5)

COURSE OUTCOMES VS POS MAPPING (DETAILED; HIGH:3; MEDIUM:2; LOW:1)

CO3 Realize design 2 2 2 1 - 1 - 1 - -

CO4 Plan a software 2 1 2 1 2 - - 1 2 -

CO5 Use modern 2 - 2 1 2 - - 1 1 -

COURSE OUTCOMES VS POS MAPPING (DETAILED; HIGH:3; MEDIUM:2; LOW:1):

PO1 Basic knowledge PO6 Environment and sustainability

PO2 Discipline knowledge PO7 Ethics

PO3 Experiments and practice PO8 Individual and team work

PO4 Tools Usage PO9 Communication

PO5 Profession and society PO10 Life-long learning

JUSTIFICATION FOR MAPPING

CO1-PO2 M An ability to apply specific knowledge to solve problems in software

CO2-PO4 L Analyze and translate a specification into a design by using appropriate

CO3-PO4 L Realize design practically, using an appropriate technologies and tools

CO4-PO8 L To perform functionality effectively as an individual, and as a member or

GAPES IN THE SYLLABUS - TO MEET INDUSTRY/PROFESSION REQUIREMENTS, POs:

SNO DESCRIPTION PROPOSED ACTIONS / ACTION TAKEN

PROPOSED ACTIONS: TOPICS BEYOND SYLLABUS/ASSIGNMENT/INDUSTRY VISIT/GUEST

TOPICS BEYOND SYLLABUS/ADVANCED TOPICS/DESIGN:

SNO DESCRIPTION PROPOSED ACTIONS / ACTION TAKEN

WEB SOURCE REFERENCES:

☐ ASSIGNMENTS  STUD. SEMINARS  TESTS/MODEL  UNIV.

INNOVATIONS IN TEACHING/LEARNING/EVALUATION PROCESSES:

PROGRAM EDUCATIONAL OBJECTIVES:

1. Become competent Computer Professionals.

2. Identify project scope and objective CO2

Develop software requirements

4. Develop software requirements CO2

Component 2 2 A4=8 3 A5=15 1 C15=15 2 A4=8 2 S*5=10

Component 3 3 A4=12 3 S4=12 1 S7=7 - 2 A7=14