SESHADRI RAO GUDLAVALLERU ENGINEERING COLLEGE

(An Autonomous Institute with Permanent Affiliation to JNTUK, Kakinada)

Seshadri Rao Knowledge Village, Gudlavalleru – 521 356.

Department of Computer Science & Engineering

HANDOUT

on

SOFTWARE ENGINEERING (R23)

A.Y.2024-25

Page | 1
 SOFTWARE ENGINEERING (R23)

Class & Sem :II [Link] –II Semester Year: 2024-2025

Branch : CSE Credits : 3
=================================================================
1. Brief History and Scope of the Subject

History of Software Engineering:

Software engineering emerged in the late 20th century as the demand for more complex and
reliable software grew, particularly in the 1960s and 1970s.

1. Early Computing (1940s - 1950s):

o Early software development was informal and unstructured, with programmers
creating machine code for individual hardware.
o Software was mainly written for scientific, military, and business applications,
with minimal attention to design or structure.
2. The Software Crisis (1960s):
o As computers and software grew in complexity, developers began facing
difficulties in maintaining, scaling, and debugging software.
o In 1968, a NATO conference in Garmisch-Partenkirchen, Germany,
highlighted the "software crisis." The term referred to the growing gap
between the increasing demand for software and the ability of programmers to
develop it on time, within budget, and with high quality.
o This led to the development of software engineering as a discipline to apply
engineering principles to software development.
3. Birth of Software Engineering (1970s):
o The first textbooks and methodologies on software engineering were
developed during this time, notably by pioneers like Winston W. Royce (who
introduced the Waterfall model) and Edsger W. Dijkstra (who promoted
structured programming).
o Structured programming was a significant milestone, emphasizing code
clarity, readability, and debugging.
4. The Rise of Methodologies (1980s - 1990s):
o Software development methodologies like Object-Oriented Programming
(OOP) and Rapid Application Development (RAD) emerged.
o Software engineering practices, including requirements analysis, design, and
testing, became more formalized and widespread.
5. Modern Software Engineering (2000s - Present):
o The introduction of Agile methodologies (like Scrum and Extreme
Programming) in the 2000s revolutionized software development by
emphasizing flexibility, collaboration, and iterative development.
o The growing focus on cloud computing, artificial intelligence (AI), machine
learning, and big data has further expanded the scope of software engineering.

Page | 2
 Scope of Software Engineering:

Software engineering – This subject covers a wide range of topics essential for the effective
design, development, testing, and maintenance of software. It incorporates both technical
skills (programming, design, testing) and project management skills (planning, risk
management, team collaboration), with the goal of producing high-quality software systems
that meet user needs and are sustainable over time.

2. Pre-Requisites
 Fundamental concepts of Basic Computer Science Knowledge.
 Programming Foundations.
 Mathematics and Logic.
 Problem-Solving and Critical Thinking.

3. Course Objectives:
 To explore the evolution of software development, including various life cycle
models.
 To analyze the complexities of software project management.
 To examine coding and testing practices and methodologies.

4. Course Outcomes:

Upon successful completion of the course, the students will able to

CO1: explain software engineering evolution, compare methodologies, and apply life
cycle models effectively
CO2: develop software projects by navigating complexities using proper estimation
and risk analysis techniques.
CO3: design robust software systems with modular, cohesive, focusing on object-
oriented analysis and design.
CO4: demonstrate coding proficiency, conduct effective testing, ensure software
reliability, and implement quality management systems.
CO5: utilize CASE tools across software life cycle models for productivity and
quality enhancement.
.
5. PROGRAMME OUTCOMES (POs)

Engineering Graduates will be able to:

1. Engineering knowledge: Apply the knowledge of mathematics, science, engineering

fundamentals, and an engineering specialization to the solution of complex engineering
problems.

Page | 3
2. Problem analysis: Identify, formulate, review research literature, and analyze complex
engineering problems reaching substantiated conclusions using first principles of
mathematics, natural sciences, and engineering sciences.
3. 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.
4. 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.
5. 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.
6. 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.
7. Environment and sustainability: Understand the impact of the professional engineering
solutions in societal and environmental contexts, and demonstrate the knowledge of, and
need for sustainable development.
8. Ethics: Apply ethical principles and commit to professional ethics and responsibilities and
norms of the engineering practice.
9. Individual and team work: Function effectively as an individual, and as a member or leader
in diverse teams, and in multidisciplinary settings.
10. 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 instructions.
11. Project management and finance: Demonstrate knowledge and understanding of the
engineering and management principles and apply these to one’s own work, as a member
and leader in a team, to manage projects and in multidisciplinary environments.
12. Life-long learning: Recognize the need for and have the preparation and ability to engage
in independent and life-long learning in the broadest context of technological change.

6. PROGRAM SPECIFIC OUTCOMES

Student will be able to

1. Design, develop, test and maintain reliable software systems and intelligent systems.
2. Design and develop web sites, web apps and mobile apps.

Page | 4
 7. Mapping of Course Outcomes with Program Outcomes:

PO1 PO2 PO3 PO4 PO5 PO6 PO7 PO8 PO9 PO9 PO10 PO11 PO12 PSO1 PSO2
CO1 3 2 2 2 2 1 1 1 2 1 2 2
CO2 3 3 2 2 2 1 2 2 2
CO3 3 3 2 2 2 1
CO4 3 2 3 1 2 1 2
CO5 3 3 2 2 2 1 1 2

8. Prescribed Text Books

1. Rajib Mall, “Fundamentals of Software Engineering”, 5th Edition, PHI.
2. Roger S. Pressman, ―Software Engineering A practitioner’s Approach,
9th Edition, Mc-Graw Hill International Edition.
9. Reference Text Books
1. Ian Sommerville, ―Software Engineering, 10th Edition, Pearson.
2. Deepak Jain, “Software Engineering, Principles and Practices”,
Oxford University Press.

10. Online Learning Resources

1. [Link]
[Link]://[Link]/web/en/app/toc/lex_auth_012 605895063871488
27_s hared/overview
[Link]://[Link]/web/en/app/toc/lex_auth_013 382690411003904
735_ shared/overview

11. Lecture Schedule / Lesson Plan

No. of Periods
[Link]. Topic
Theory Tutorial
Unit - I
Introduction: Evolution-Evolution of an Art into an
1 Engineering Discipline, Evolution Pattern for Engineering 2
Disciplines, A Solution to the Software Crisis
Software Development Projects- Program Vs Products,
2 1
Software Development Projects
3 Exploratory Style of Software Development 1
4 Software Life cycle Models-Basic concepts 1 1
Waterfall model and its extensions-Classical Waterfall Model,
5 1
Iterative Waterfall Model.
6 prototyping model 1

Page | 5
 No. of Periods
[Link]. Topic
Theory Tutorial
Agile development model-Extreme Programming Model,
7 2
Scrum Model.
8 Spiral model 1 1
10 2
Unit - II
Software Project Management-Software project management
1 1
complexities
2 Responsibilities of a software project manager 1
Metrics for project size estimation-Lines of Code (LOC),
3 2 1
Function Point (FP) Metric
Project estimation techniques-Basic COCOMO, Intermediate
4 3 2
COCOMO, Complete COCOMO
Risk management- .Risk Identification, Risk Assessment, Risk
5 2
Mitigation
Requirements Analysis And Specification- Requirements
6 1
Gathering and Analysis
Software Requirements Specification (SRS)- Users of SRS
Document, Characteristics of a Good SRS Document,
Attributes of Bad SRS Documents, Important Categories of
7 Customer Requirements, Functional Requirements, How to 3
Identify the Functional Requirements?, How to Document the
Functional Requirements?, Organisation of the SRS
Document.
13 3
Unit - III
1 Software Design: Overview of the design process 1
2 How to Characterise a Good Software Design 1
3 Layered arrangement of modules 1
4 Cohesion and Coupling 1
Approaches to software design - Function-oriented Design,
5 2
Object-oriented Design
Function- Oriented Software Design: Structure Charts -
6 Overview of SA/SD Methodology, Data Flow Diagrams 2 1
(DFDs)
Structure design methodology - Transformation of a DFD
7 1
Model into Structure Chart
Object Oriented Design: Basic object orientation Concepts,
7 1
Class Relationships.
Unified Modeling Language – UML Diagrams
8 Use case Model , Class diagram, Interaction diagram, Activity 2 1
Diagram, State chart Diagram, Component and Deployment

Page | 6
 No. of Periods
[Link]. Topic
Theory Tutorial
diagrams.

12 2
Unit - IV
1 Coding and Testing: Coding-Coding standards and guidelines 1
2 Testing-Basic Concepts and Terminologies, Testing Activities 1
black box testing-Equivalence Class Partitioning, Boundary
3 1 1
Value Analysis
white box testing-white box testing, Branch Coverage,
4 Multiple Condition Coverage, .Path Coverage, McCabe’s 2 1
Cyclomatic Complexity Metric .
5 Integration testing 1
6 Smoke Testing 1
Software Reliability And Quality Management: Software
7 reliability-Hardware versus Software Reliability, Reliability 1
Metrics of Software Products
8 ISO 9000-What is ISO 9000 Certification? 1
9 SEI Capability maturity model – CMM levels 1
10 2
Unit - V
Computer-Aided Software Engineering (CASE): CASE
1 1
and its scope
2 CASE environment 1
3 CASE Support in Software Life Cycle 1
Software Maintenance: Characteristics of software
4 1
maintenance
5 Software reverse engineering 1
6 Software maintenance process models 1 1
7 Estimation of maintenance cost 1
7 1
Total No. of Periods: 52 10

Page | 7
 R23 Software Engineering II [Link]

SOFTWARE ENGINEERING

Unit-I: Introduction and Software Life Cycle Models

Objective:
To explore the evolution of software development, including various life cycle models.

Syllabus:

Introduction: Evolving - From an art form to an Engineering Discipline, Software

Development Projects, Exploratory Style of Software Development, Life Cycle Models-
Classical waterfall model, Iterative waterfall model, Prototyping model, agile development
models and spiral models.

Modules:
Module 1: Evolution-Evolution of an Art into an Engineering Discipline.
Module 2: Software Development Projects.
Module 3: Exploratory Style of Software Development.
Module 4: Software Life cycle Models-Basic concepts.

Learning Outcomes:

At the end of the unit student will be able to:

 explain software engineering evolution, compare methodologies, and apply life
cycle models effectively.

Learning Material
Introduction:

Software:
 Software is a set of instructions or programs instructing a computer to do specific
tasks.
 Software is a set of
 Instructions that when executed provide desired function and performance,
 Data Structures that enable the programs to adequately manipulate
information,
 Documents that describe the operation and use of the programs.

Engineering:
Engineering is the application of mathematics, science, economics, social and practical
knowledge to invent, innovate, design, build, maintain and research.

Seshadri Rao Gudlavalleru Engineering College AS&A 2024-2025 Page 1

 R23 Software Engineering II [Link]

Software Engineering:
The application of a systematic, disciplined, quantifiable approach to the development,
operation, and maintenance of software.

Module 1: Evolution- From an Art form to an Engineering Discipline

1.1 Evolution of an Art into an Engineering Discipline:
 The early programmers used an exploratory (also called build and fix or code and fix) style.
 In the build and fix (exploratory) style, normally a program is quickly developed without making any
specifications, plan or design.
 The different imperfections that are subsequently noticed are fixed.
 The exploratory programming style is informal style in the sense that there are no set of rules or
recommendations.
 Every programmer evolves his own software development techniques guided by his own intuition,
experience and fancies.

1.1.1 Evolution Pattern for Engineering Disciplines:

• If we analyze the evolution of the software development styles over the last sixty years, we can easily
noticed that it has evolved from an esoteric art form to a craft form , and then emerged as an
engineering discipline.
• Evolution of technology has followed the similar patterns for iron making, paper making, building
construction or software development.
• Example: Iron making technology

Figure 1: Evolution of technology with time.

1.1.2 A Solution to the Software Crisis:

 Organizations are spending increasingly larger portions of their budget on software as compared
to that on hardware.
 Among all the symptoms of the present software crisis, the trend of increasing software costs is
probably the most vexing.

Seshadri Rao Gudlavalleru Engineering College AS&A 2024-2025 Page 2

 R23 Software Engineering II [Link]

Figure 2: Relative changes of hardware and software costs over time.

Not only are the software products becoming progressively more expensive than hardware, but they also
present a host of other problems to the customers—software products are difficult to alter , debug, and
enhance; use resources non-optimally; often fail to meet the user requirements; are far from being
reliable; frequently crash; and are often delivered late.
The factors that have contributed to the present software crisis are rapidly increasing
problem size, lack of adequate training in software engineering techniques, increasing skill shortage,
and low productivity improvements.
It is believed that a satisfactory solution to the present software crisis can possibly come
from a spread of software engineering practices among the developers, coupled with further
advancements to the software engineering discipline itself.

Module 2. SOFTWARE DEVELOPMENT PROJECTS:

Software development projects in software engineering are structured endeavors to design, build, and
deploy software solutions to address specific needs or problems. They provide a systematic approach to
transforming ideas into tangible, functional software products.
2.1 Programs versus Products:
 Many toys software is being developed by individuals such as students for their classroom
assignments and hobbyists for their personal use.
 These are usually small in size and support limited functionalities.
 Further, the author of a program is usually the sole user of the software and himself maintains the
code.
 These toy software therefore usually lack good user-interface and proper documentation.
 In contrast, professional software usually has multiple users and, therefore, has good user-interface,
proper user’s manuals, and good documentation support.
 A further difference is that professional software is often too large and complex to be developed by
any single individual. It is usually developed by a group of developers working in a team.

Seshadri Rao Gudlavalleru Engineering College AS&A 2024-2025 Page 3

 R23 Software Engineering II [Link]

2.2 Types of Software Development Projects:

A software development company is typically structured into a large number of teams that handle
various types of software development projects. These software development projects concern the
development of either software product or some software service.

2.2.1 Software products:

 Microsoft’s Windows and the Office suite, Oracle DBMS, software accompanying a camcorder
or a laser printer are called generic software products.
 When a software development company wishes to develop a generic product, it first determines
the features or functionalities that would be useful to a large cross section of users.
 Based on these, the development team draws up the product specification on its own. Of course,
it may base its design discretion on feedbacks collected from a large number of users.
 For example, Microsoft targets desktops and laptops through its Windows 8 operating system,
while it targets high-end mobile handsets through its Windows mobile operating system, and
targets servers through its Windows server operating system.
2.2.2 Software services:
 A software service usually involves either development of a customized software or
development of some specific part of software in an outsourced mode.
 Customized software is developed according to the specification drawn up by one or at most a
few customers.
 These need to be developed in a short time frame (typically a couple of months), and at the same
time the development cost must be low.
 Usually, a developing company develops customized software by tailoring some of its existing
software. For example, when an academic institution wishes to have software that would
automate its important activities such as student registration, grading, and fee collection;
companies would normally develop such software as a customized product.

Module 3. EXPLORATORY STYLE OF SOFTWARE DEVELOPMENT

 Exploratory program development style refers to an informal development style or builds and
fixes the style in which the programmer uses his own intuition to develop a program rather
than making use of the systematic body of knowledge which is categorized under the software
engineering discipline.
 This style of development gives complete freedom to programmers to choose activities which
they like to develop software. This dirty program is quickly developed and bugs are fixed
whenever it arises.
 This style does not offer any rules to start developing any software. The following block
diagram will clear some facts relating to this model.

Seshadri Rao Gudlavalleru Engineering College AS&A 2024-2025 Page 4

 R23 Software Engineering II [Link]

Figure 3: Exploratory program development

 In the above diagram, the first block is the initial briefing by the customer i.e. brief
introduction of the problem by the customer.
 After the briefing, control goes to initial coding i.e. as soon as the developer or programmer
knew about the problem he starts coding to develop a working program without considering
any kind of requirement analysis.

 After this, the program will be tested i.e. bugs found and they are getting fixed by
programmers.
 This cycle continues until satisfactory code is not obtained. After finding satisfactory code,
development gets completed.

3.1 What’s wrong with this model?

In an exploratory development scenario, the effort and time required to develop professional software
increase with an increase in program size. An increase in development effort and time with problem
size has been indicated in the following figure.

Figure 4: Increase in development time and effort with problem size.

Seshadri Rao Gudlavalleru Engineering College AS&A 2024-2025 Page 5

 R23 Software Engineering II [Link]

 In the above figure, the thick line plots represent the case in which the exploratory style is
used to develop a program.
 As program size increases, required effort and time increase almost exponentially. For large
problems, it would take too long and cost too much to be practically meaningful to develop a
program using the exploratory style of development.
 The exploratory development approach is said to break down after the size of the program to
be developed increases beyond a certain value.
 The thin solid line is used to represent a case when development is carried out using software
engineering principles.
 In this case, it becomes possible to solve a problem with effort and time that is almost linear in
program size dotted line is used to represent a case when development is carried out by an
automated machine.
 In this case, an increase in effort and time with size would be even closer to a linear increase
with size.
 Exploratory style causes perceived difficulty of a problem to grow exponentially due to human
cognitive limitations because whenever the case arises in which a number of independent
variables increase in the project then it is beyond the grasping power of an individual and due
to this requires more effort.
 You may still wonder that when software engineering principles are used, why the curve not
becomes completely linear. The answer is that it is very difficult to apply decomposition and
abstraction principles to completely overcome problem complexity.

3.2 The shortcoming of this model:

 Using this model, there is the exponential growth of development time effort and cost with problem
size and large-sized software becomes almost impossible using this style of development.
 This style of development results in unmaintainable code because programming without planning
always results in unstructured and poor-quality code.
 Also, it is difficult to use this style when there is a proper developing team because in this style every
developer uses his own intuition to develop software.

Module 4. Life Cycle Models

 A software life cycle model is a descriptive and diagrammatic representation of the software life cycle.
 The software engineering approaches emphasize software development through a well-defined and
ordered set of activities. If these activities are graphically modeled as well as textually described then it
is called as Software Life cycle Model.
 Software Life cycle Model is also called as Software Development Life Cycle Model or Software
Development Process Model.
 The life cycle of software represents the series of identifiable stages through which it evolves during its
life time.

4.1 The need for a software life cycle model

 The development team must identify a suitable life cycle model for the particular project and then
adhere to it.

Seshadri Rao Gudlavalleru Engineering College AS&A 2024-2025 Page 6

 R23 Software Engineering II [Link]
 Without using of a particular life cycle model, the development of a software product would not be in a
systematic and disciplined manner.
 When a software product is being developed by a team there must be a clear understanding among team
members about when and what to do.
 A software life cycle model defines entry and exit criteria for every phase.

4.1.1 Classical waterfall model

4.1.2 Iterative waterfall model
4.1.3 Prototyping model
4.1.4 Agile Development model
4.1.5 Spiral model

4.1.1 Classical waterfall model

 The waterfall model is a classical development process model proposed by Winston Walker
Royce in 1970.

 The simplest process model is the waterfall model, which states that the phases are linear order.

 Classical waterfall model divides life cycle into phases:

 feasibility study
 requirements analysis and specification
 design
 coding and unit testing
 integration and system testing
 maintenance

Figure 5: Classical Waterfall Model

Relative Effort distribution among different phases

• Phases between feasibility study and testing known as development phases.

Seshadri Rao Gudlavalleru Engineering College AS&A 2024-2025 Page 7

 R23 Software Engineering II [Link]
• Among all life cycle phases maintenance phase consumes maximum effort.

• Among development phases, testing phase consumes the maximum effort.

Feasibility Study
 Main aim of feasibility study is to determine whether it would be financially and technically feasible to
develop the software.
 First roughly understand what the customer wants: different data which would be input to the system,
processing needed on these data, output data to be produced by the system, various constraints on the
behaviour of the system.
 Development of an overall understanding of the problem.
 Evolution of different solution strategies in terms of: resources required, cost of development, and
development time.

Requirements Analysis and Specification

• This phase is to understand the exact requirements of the customer document them properly.
• It consists of two distinct activities: requirements gathering and analysis and requirements specification.

Requirements Gathering and Analysis

• Collect all related data from the customer: analyse the collected data to clearly understand what the
customer wants, find out any inconsistencies and incompleteness in the requirements, resolve all
inconsistencies and incompleteness.

Requirements Specification
• After the requirements gathering and analysis the identified requirements are documented. This is a
Software Requirements Specification (SRS) document.

Design
• Design phase transforms requirements specification into a form suitable for implementation in some
programming language.
• During design phase, software architecture is derived from the SRS document.
• Two design approaches are used at present:
– Procedural Design approach
– Object oriented Design approach.

Seshadri Rao Gudlavalleru Engineering College AS&A 2024-2025 Page 8

 R23 Software Engineering II [Link]

Procedural Design approach

• It consists of two activities:
– Structured analysis (typically carried out by using DFD)
– Structured design

Object Oriented Design

• First identify various objects (real world entities) occurring in the problem: identify the relationships
among the objects.
• For example, the objects in a pay-roll software may be: employees, managers, pay-roll register,
Departments, etc.

Coding and unit testing

 This phase is to translate software design into source code.

 This phase is also called as Implementation phase.
• During the implementation phase: each module of the design is coded, each module is unit tested and
debugged.
• The purpose of unit testing: test if individual modules work correctly.
• The end product of implementation phase is a set of program modules that have been tested
individually.

Integration and System Testing

• Different modules are integrated in a planned manner:

• During each integration step, the partially integrated system is tested.

System Testing
• After all the modules have been successfully integrated and tested system testing is carried out.
• Goal of system testing is to ensure that the developed system functions according to its requirements as
specified in the SRS document.

Maintenance
• Maintenance of any software product requires much more effort than the effort to develop the product
itself.
• The ratio of development effort to maintenance effort is typically 40:60.
• Maintenance is required in three situations.

Seshadri Rao Gudlavalleru Engineering College AS&A 2024-2025 Page 9

 R23 Software Engineering II [Link]

Corrective maintenance:
Correct errors which were not discovered during the product development phases.
Perfective maintenance:
Improve implementation of the system
enhance functionalities of the system.
Adaptive maintenance:
Port software to a new environment,
e.g. to a new computer or to a new operating system.

Advantages of Waterfall Model:

 Simple and easy to understand and use.
 Easy to manage due to the rigidity of the model.
 Phases are processed and completed one at a time.
 Works well for smaller projects where requirements are very well understood.
Disadvantages of waterfall model:
 You cannot go back a step; if the design phase has gone wrong, things can get very complicated
in the implementation phase.
 High amounts of risk and uncertainty.
 Not a good model for complex and object-oriented projects.
 Poor model for long and on-going projects.
 Not suitable for the projects where requirements are at a moderate to high risk of changing.
 No Feedback path.
 Inefficient error corrections.
 No overlapping of phases

4.1.2 Iterative Waterfall Model

 The main change brought about by the Iterative Waterfall model to the Classical Waterfall model is in
the form of feedback paths from every phase to its preceding phases.

 The feedback paths allow for correcting errors committed by a programmer during some phase, as and
when these are detected in a later phase.

 For example, if during test phase design error is identified, then the feedback path allows the design to
be reworked and the change to be reflected in the design documents

 There is no feedback path to the feasibility phase because once a team accepted to take up a project,
they does not give up the project easily due to legal and moral reasons.

Seshadri Rao Gudlavalleru Engineering College AS&A 2024-2025 Page 10

 R23 Software Engineering II [Link]

Figure 6: Iterative Waterfall Model

 Errors should be detected in the same phase in which they are introduced, so that early detection of
errors reduces the effort and time.

 For example, if a design problem is detected in the design phase itself, the problem can be taken care of
much more easily than if it is identified at the end of the testing phase.

Figure 7: Distribution of effort for various phases in the iterative waterfall model.
 Rework must be carried out not only to the design but also to code and test phases.
 The principle of detecting errors as close to their point of commitment as possible is known as phase
containment of errors.
 Iterative waterfall model is the most widely used model almost every other model is derived from the
waterfall model.

Disadvantages of Iterative Waterfall model

 Difficult to accommodate change requests
 Incremental delivery not supported
 Phase overlap not supported
 Error correction is expensive
 Limited customer interactions
 Heavy documentation
 No support for risk handling and code reuse.

Seshadri Rao Gudlavalleru Engineering College AS&A 2024-2025 Page 11

 R23 Software Engineering II [Link]

4.1.3 Prototyping Model

 The prototyping model is also an extension of waterfall model.
 This model suggests building a working prototype of the system before development of actual software.
 A prototype is a toy and implementation of a system. It has limited functional capabilities, low
reliability, and inefficient performance as compared to actual software.

Necessity of the prototyping model

 This model is advantageous for specific type of projects. We identify three types of projects for which
prototyping model is followed:
1. It is advantageous to use the prototyping model for development of the graphical user interface (GUI)
part of an application.
Through the use of a prototype, it becomes easier to illustrate the input data formats, messages, reports,
and the interactive dialogs to the customer.
The GUI part of a software system is almost always developed using the prototyping model.
2. The prototyping model is especially useful when the exact technical solutions are unclear to the
development team. A prototype can help them to critically examine the technical issues associated with
product development.
3. An important reason for developing a prototype is that it is impossible to “get it right” the first time. As
advocated by Brooks [1975], one must plan to throw away the software in order to develop a good
software later.
 Thus, the prototyping model can be deployed when development of highly optimised and efficient
software is required.
 The prototyping model is considered to be useful for the development of not only the GUI parts of a
software, but also for a software project for which certain technical issues are not clear to the
development team.

[Link] Life cycle activities of prototyping model

• In prototyping model software is developed through two major activities

1. Prototype construction and
2. Iterative waterfall-based software development
• Prototype development:
• Prototype development starts with an initial requirement gathering phase.
• A quick design is carried out and a prototype is built.
• The developed prototype is submitted to the customer for evaluation.
• Based on the customer feedback, the requirements are refined and the prototype is suitably modified.
• This cycle of obtaining customer feedback and modifying the prototype continues till the customer
approves the prototype.

Seshadri Rao Gudlavalleru Engineering College AS&A 2024-2025 Page 12

 R23 Software Engineering II [Link]

Iterative development
• Once the customer approves the prototype, the actual software is developed using the iterative waterfall
approach.
• In spite of the availability of a working prototype, the SRS document is usually needed to be developed
since the SRS document is invaluable for carrying out traceability analysis, verification, and test case
design during later phases.
• T h e code for the prototype is usually thrown away. However, the experience gathered from developing
the prototype helps a great deal in developing the actual system.

Figure 8: Prototyping model of software development.

• Even though the construction of a throwaway prototype might involve incurring additional cost, for
systems with unclear customer requirements and for systems with unresolved technical issues, the
overall development cost usually turns out to be lower compared to an equivalent system developed
using the iterative waterfall model.

Strengths of Prototyping Model

• This model is the most appropriate for projects that suffer from technical and requirements risks. A
constructed prototype helps overcome these risks.
• It is cost-cutting measure by reducing testing.
• The experience of developing the prototype will reduce the cost entire project.
• As requirements will be more stable now due to the feedback from the prototype, there will be fewer
changes in the requirements.
• Developing the prototype will enable them to create a better design, write better code, and do better
testing.

Seshadri Rao Gudlavalleru Engineering College AS&A 2024-2025 Page 13

 R23 Software Engineering II [Link]

Disadvantages
 It is a slow process.
 Too much involvement of client is not always preferred by the developer.
 Too many changes can disturb the rhythm of the development team.
 Practically, this methodology may increase the complexity of the system as scope of the system
may expand beyond original plans.
 If client is not satisfied with the developed prototype, new prototype should be made, this may
lead to be expensive

4.1.4 Agile Development Models

 The agile software development model was proposed in the mid-1990s to overcome the shortcomings of
the waterfall model.
 The agile model was primarily designed to help a project to adapt to change requests quickly.
 The major aim of the agile models is to facilitate quick project completion.
 Agility is achieved by fitting the process to the project, i.e. removing activities that may not be
necessary for a specific project. Also, anything that that wastes time and effort is avoided.
 Agile model is being used as an umbrella term to refer to a group of development process. A few
popular agile SDLC models are the following:
The most popular methods are
 Extreme programming (XP)
 Scrum

[Link] Extreme Programming (XP) Model

 Extreme programming (XP) is an important process model under the agile umbrella and was proposed
by Kent Beck in 1999.
 The name of this model reflects the fact that it recommends taking these best practices that have worked
well in the past in program development projects to extreme levels.
 This model is based on a rather simple philosophy:” If something is known to be beneficial, why not
put it to constant use.

Figure 9 : Extreme Programming Process

Seshadri Rao Gudlavalleru Engineering College AS&A 2024-2025 Page 14

 R23 Software Engineering II [Link]
Planning: -
Planning activity begins with creation of a set of Stories.
• Each story is written by the customer and is placed on an index card.
• Customer assigns a priority. If the story will require more than three development weeks the customer is
asked into split the story into smaller stories.
• Once a basic commitment is made for release the XP team order the basic stories that will be developed
in 3 weeks
->All the stories will be implemented immediately
->The stories with highest value will be moved up in the schedule and implement first.

Design:
Without proper design, a system implementation becomes too complex and the dependencies within the
system become too numerous and it becomes very difficult to comprehend the solution, and thereby
making maintenance prohibitively expensive.
• A good design should result in elimination of complex dependencies within a system.
• XP design Follows Keep it simple (KIS) Principle.
• XP encourage the use of CRC (Class responsibility collaborator) cards which identify and organize the
object oriented classes.
• The CRC cards are the only design work product produced as part of the XP process.
• If a difficult design problem is encountered as part of the design of a story, XP recommends the
immediate creation of an operational prototype of that portion of the design called a Spike solution.

Coding:
• It suggests pair programming as the way to achieve continuous review.
• It is good since it helps detect and correct problems most efficiently.
• In pair programming, coding is carried out by pairs of programmers. The programmers take turn in
writing programs and while one write the other reviews code that is being written.
• Refactoring is the process of improving the design of the code after it has written.

Testing:
Testing code helps to remove bugs and improves its reliability.
• XP suggests Test driven development (TDD) to continually write and execute test cases.
• In the TDD approach, test cases are written even before any code is written. XP places high importance
on testing and considers it be the primary means for developing a fault-free software.

Advantages of Extreme Programming (XP)

 Built-In Quality
 Overall Simplicity
 Programmer Power
 Customer Power

Disadvantages of Extreme Programming (XP)

 Informal, little, or no documentation
 Scalability
 Contract Issues
 Misconception on the cost of change

Seshadri Rao Gudlavalleru Engineering College AS&A 2024-2025 Page 15

 R23 Software Engineering II [Link]

[Link] Scrum Model

• In scrum model, a project is divided into small parts of work that can be incrementally developed and
delivered over time boxes that are called sprints.
• The software therefore gets developed over a series of manageable chunks.
• Each sprint typically takes only a couple of weeks to complete. At the end of each sprint, stakeholders
and team members meet to assess the progress made and the stakeholders suggest to the development
team any changes needed to features that have already been developed and any overall improvements
that they might feel necessary.
• In the scrum model, the team members assume three fundamental roles— software owner, scrum
master, and team member.

Product Owner
• Possibly a Product Manager or Project Sponsor
• Decides features, release date, prioritization
Scrum Master
• Typically, a Project Manager or Team Leader
• Responsible for enacting Scrum values and practices
• Remove impediments / politics, keeps everyone productive
Project Team
• 5-10 members; Teams are self-organizing
• Cross-functional: QA, Programmers, UI Designers, etc.
• Membership should change only between sprints
• Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest
time.
• There are some roles in the scrum process
Pigs and Chickens
• Pigs’ groups include
• Product owner
• Scrum master and
• Scrum team
• Chicken group involves
• Users
• Stakeholders
• managers
• Pig: Team member committed to success of project
• Chicken: Interested but not committed

Seshadri Rao Gudlavalleru Engineering College AS&A 2024-2025 Page 16

 R23 Software Engineering II [Link]

Advantages
 Scrum can help team’s complete project quickly and efficiently.
 Scrum ensures effective use of time and money.
 Large projects are divided into easily manageable sprints.
 Developments are coded and tested during the sprint review.
 Works well for fast-moving development projects.
 The team gets clear visibility through scrum meetings.

Seshadri Rao Gudlavalleru Engineering College AS&A 2024-2025 Page 17

 R23 Software Engineering II [Link]
Disadvantages
 The chances of project failure are high if individuals aren't very committed or cooperative.
 Adopting the Scrum framework in large teams is challenging.
 The framework can be successful only with experienced team members.
 Daily meetings sometimes frustrate team members.
 If any team member leaves in the middle of a project, it can have a huge negative impact on the project.

4.1.5. 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.

Figure: Spiral model of software development

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.

Seshadri Rao Gudlavalleru Engineering College AS&A 2024-2025 Page 18

 R23 Software Engineering II [Link]
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:

 Software is produced early in the software life cycle.

 Risk handling is one of important advantages of the Spiral model, it is best development model to
follow due to the risk analysis and risk handling at every phase.
 Flexibility in requirements. In this model, we can easily change requirements at later phases and can be
incorporated accurately. Also, additional Functionality can be added at a later date.
 It is good for large and complex projects.
 It is good for customer satisfaction. We can involve customers in the development of products at early
phase of the software development. Also, software is produced early in the software life cycle.
 Strong approval and documentation control.
 It is suitable for high-risk projects, where business needs may be unstable. A highly customized product
can be developed using this.

Disadvantages of Spiral Model:

 It is not suitable for small projects as it is expensive.

 It is much more complex than other SDLC models.
 Too much dependable on risk analysis and requires highly specific expertise.
 Difficulty in time management. As the number of phases is unknown at the start of the project, so time
estimation is very difficult.
 Spiral may go on indefinitely.
 End of the project may not be known early.
 It is not suitable for low-risk projects.
 May be hard to define objective, verifiable milestones. Large numbers of intermediate stages require
excessive documentation.

Seshadri Rao Gudlavalleru Engineering College AS&A 2024-2025 Page 19

R23 Software Engineering II [Link]
Assignment-Cum-Tutorial Questions
Part-A
Objective Questions (1M)

1. What is Software? [ ]
a) Software is set of programs.
b) Software is documentation and configuration of data.
c) Both a and b
d) None of the mentioned

2. What are the characteristics of software? [ ]

a) Software is developed or engineered; it is not manufactured in the classical sense.
b) Software does not wear out.
c) Software can be custom built or custom build.
d) All mentioned above

3. The process of developing a software product using software engineering principles and
methods is referred to as, ______________. [ ]
a) Software myths
b) Scientific Product
c) Software Evolution
d) None of the above

4. Software consists of __________. [ ]

a) Set of instructions + operating procedures
b) Programs + documentation + operating procedures
c) Programs + hardware manuals
d) Set of program

5. The extent to which the software can continue to operate correctly despite the introduction
of invalid inputs is called as [ ]
a) Reliability
b) Robustness
c) Fault Tolerance
d) Portability
e) All of the above

6. As per an IBM report, 31% of the project get cancelled before they are completed, 53%
overrun their cost estimates by an average of 189% and for every 100 projects, there are 94
restarts. What is the reason for these statistics? [ ]
a) Lack of adequate training in software engineering
b) Lack of software ethics and understanding
c) Management issues in the company
d) All of the mentioned

Seshadri Rao Gudlavalleru Engineering College AS&A 2024-2025 Page 20

 R23 Software Engineering II [Link]
7. Compilers, Editors software comes under which type of software? [ ]
a) System software
b) Application software
c) Scientific software
d) None of the above

8. Which of the following cannot be applied with the software according to Software
Engineering Layers? [ ]
a) Process
b) Methods
c) Manufacturing
d) None of the above

9. Choose the correct option according to the given statement. [ ]

 Statement 1: Software is a physical rather than a logical system element.

 Statement 2: Computer software is the product that software engineers design and
build.
 Statement 3: Software is a logical rather than a physical system element.
 Statement 4: Software is a set of application programs that are built by software
engineers.

a) Statement 1 and 2 are correct.

b) Only Statements 2 and 3 are correct.
c) Statements 2, 3, and 4 are correct.

10. From the following which quality deals with maintaining the quality of the software
product? [ ]
a) Quality assurance
b) Quality control
c) Quality efficiency
d) None of the above

11. Which one of the following is not a symptom of the present software crisis? [ ]
a) Software is expensive.
b) It takes too long to build a software product.
c) Software is delivered late.
d) Software products are required to perform very complex tasks.

12. Which one of the following characteristics of software products being developed is not a
symptom of software crisis? [ ]
a) Fail to meet user requirements
b) Expensive
c) Highly interactive
d) Difficult to alter, debug, and enhance

13. Why is writing easily modifiable code important? [ ]

a) Easily modifiable code results in quicker run time

Seshadri Rao Gudlavalleru Engineering College AS&A 2024-2025 Page 21

R23 Software Engineering II [Link]
b) Most real-world programs require change at some point of time or other
c) Most text editors make it mandatory to write modifiable code
d) Several developers may write different parts of a large program

14. Which one of the following is not a symptom of the present software crisis? [ ]
a) Software is expensive.
b) It takes too long to build a software product.
c) Software is delivered late.
d) Software products are required to perform very complex tasks.

15. Which one of the following characteristics of software products being developed is not a
symptom of software crisis? [ ]
a) Fail to meet user requirements.
b) Expensive.
c) Highly interactive.
d) Difficult to alter, debug, and enhance.

16. Model building is based on which one of the following techniques? [ ]

a) Abstraction
b) Decomposition
c) Aggregation
d) Composition

17. Which one among the following is not a software service type of project? [ ]
a) Software maintenance
b) Software customization
c) Outsourced software development
d) Software product development

18. Which one among the following is not a software service type of project? [ ]
a) Software maintenance
b) Software customization
c) Outsourced software development
d) Software product development

Part-B
Short Answer Questions (2M)

1. What is meant by the term "software crisis," and how does it relate to the evolution of
software engineering?
2. Distinguish between a software program and a software product. Provide one example for
each.
3. Explain the main drawback of the exploratory style of software development.
4. List the key phases of the software development life cycle (SDLC).
5. What are the major differences between the classical waterfall model and the iterative
waterfall model?
6. How does the prototyping model address the challenge of unclear user requirements?

Seshadri Rao Gudlavalleru Engineering College AS&A 2024-2025 Page 22

 R23 Software Engineering II [Link]
7. Name one advantage and one disadvantage of using the Agile development model.
8. In the Scrum model, what is the primary role of the Product Owner?
9. What makes the Spiral Model suitable for risk-heavy projects?
10. Why is the Extreme Programming (XP) model particularly effective in projects with
frequent requirement changes?

Part-C
Descriptive Questions (5M)

1 Why do you think systematic software development using the software [BL2]
engineering principle is any different than art or craft?
2 Distinguish between a program and professionally developed software. [BL2]
3 Distinguish among a program, a software product and a software service. [BL2]
Give one example of each. Discuss the difference of the characteristics of
development projects for each of these.
4 Do you agree with the following statement—The focus of exploratory [BL4]
programming is error correction while the software engineering principles
emphasise error prevention”? Give the reasonings behind your answer.
5 What difficulties would a software development company face, if it tries [BL2]
to use the exploratory (build and fix) program development style in its
development projects? Explain your answer.
6 What are the symptoms of the present software crisis? What factors [BL2]
have contributed to the making of the present software crisis? What are
the possible solutions to the present software crisis?
7 Explain why the effort, time, and cost required to develop a program [BL2]
using the build and fix style increase exponentially with the size of the
Program? How do software engineering principles help tackle this rapid
rise in development time and cost?
8 List the major differences between the exploratory and modern [BL4]
software development practices.
9 What do you understand by the term software life cycle? Why is it [BL2]
necessary to model software life cycle and to document it?
10 What do you understand by the term software development life cycle [BL5]
model (SDLC)?
What problems might a software development organization face if it is
not following any SDLC for development of a large-sized software?
11 What problems would a software development organization face if it does not have a [BL2]
documented process model, and therefore follows only an informal one?
12 What do you mean by a software development process? What is the [BL3]
difference between a methodology and a process? Explain your answer
using a suitable example.
13 Which are the major phases in the waterfall model of software [BL2]
development? Which phase consumes the maximum effort for developing
a typical software?

Seshadri Rao Gudlavalleru Engineering College AS&A 2024-2025 Page 23

 R23 Software Engineering II [Link]

14 Consider the following assertion: “The classical waterfall model is an [BL5]

idealistic model”.
Based on this assertion, answer the following:
(a) Justify why the above assertion is true.
(b) Even if the classical waterfall model is an idealistic model, is there
any practical use of this model at all? Explain your answer.
15 Draw a schematic diagram to represent the iterative waterfall model of [BL3]
software development. On your diagram represent the following:
(a) The phase entry and exit criteria for each phase.
(b) (b) The deliverables that need to be produced at the end of each
phase.
16 What are the objectives of the feasibility study phase of software [BL2]
development? Explain the important activities that are carried out during
the feasibility study phase of a software development project. Who
carries out these activities? Mention suitable phase entry and exit criteria
for this phase.
17 Give an example of a software development project for which the [BL5]
iterative waterfall model is not suitable. Briefly justify your answer.
18 In practical software development projects using iterative waterfall [BL4]
SDLC, why do different phases overlap? Explain the effort distribution
over different phases.
19 Identify five reasons as to why the customer requirements may change [BL4]
after the requirements phase is complete and the SRS document has
been signed off.
20 Which life cycle model would you follow for developing software for [BL3]
each of the following applications? Mention the reasons behind your
choice of a particular life cycle model.
(a) A well-understood data processing application.
(b) A new software that would connect computers through satellite
communication.
Assume that your team has no previous experience in developing
satellite communication software.
(c) A software that would function as the controller of a telephone
switching system.
(d) A new library automation software that would link various libraries in
the city.
(e) An extremely large software that would provide, monitor, and control
cellular communication among its subscribers using a set of revolving
satellites.
(f ) A new text editor.
(g) A compiler for a new language.
(h) An object-oriented software development effort.
(i) The graphical user interface part of a large software.
21 With respect to the prototyping model for software development, [BL4]
answer the following:
(a) What is a prototype?
(b) Is it necessary to develop a prototype for all types of projects?
(c) If you answer to part (b) of the question is no, then mention under
Seshadri Rao Gudlavalleru Engineering College AS&A 2024-2025 Page 24
 R23 Software Engineering II [Link]
what circumstances is it beneficial to construct a prototype.
(d) If your answer to part (b) of the question is yes, then explain does
construction of a prototype always increase the overall cost of software
development.
22 If the prototyping model is being used in a development project of [BL5]
moderate size, is it necessary to develop an SRS document? Justify your
answer.
23 Consider that a software development project that is beset with many [BL4]
risks. But, assume that it is not possible to anticipate all the risks in the
project at the start of the project and some of the risks can only be
identified much after the development is underway. As the project
manager recommend the use of the prototyping or the spiral model?
Explain your answer.
24 What are the major advantages of first constructing a working [BL2]
prototype before starting to develop the actual software? What are the disadvantages of
this approach?
25 Explain how a software development effort is initiated a n d finally [BL2]
terminated in the spiral model.
26 Suppose a travel agency needs a software for automating its book keeping activities. The
[BL4]
set of activities to be automated are rather simple
and are at present being carried out manually. The travel agency has
indicated that it is unsure about the type of user interface which would be
suitable for its employees and its customers. Would it be proper for a
development team to use the spiral model for developing this software?
27 Explain why the spiral life cycle model is considered to be a meta [BL2]
model.
28 Both the prototyping model as well as the spiral model have been [BL3]
designed to handle risks. Identify how exactly risk is handled in each.
How do these two models can be compared with respect to their risk
handling capabilities?
28 Explain with suitable examples, the types of software development for [BL4]
which the spiral model is suitable. Is the number of loops of the spiral
fixed for different development projects? If not, explain how the number
of loops in the spiral is determined.
29 Briefly explain the agile software development model. Give an example [BL2]
of a project for which the agile model would be suitable and one project
project for which the agile model would not be appropriate.
30 Briefly explain the extreme programming (XP) SDLC model. Identify the [BL2]
key principles that need to be practised to the extreme in XP. What is a
spike in XP? Why is it required?
31 What do you understand by pairwise programming? What are its [BL2]
advantages over traditional programming?

Seshadri Rao Gudlavalleru Engineering College AS&A 2024-2025 Page 25

 R23 Software Engineering II [Link]

Part-D
Competitive Examination Questions

Q.1 - UGC NET DEC 2023

The prototyping model has the sequence:
(A) Customer Evaluation (B) Quick design (C) Requirements (D) Implement (E) Design
Choose the correct answer from the options given below:
i) (C) -> (A) -> (D) -> (B) -> (E)
ii) (B) -> (C) -> (A) -> (D) -> (E)
iii) (C) -> (B) -> (D) -> (A) -> (E)
iv) (E) -> (B) -> (C) -> (D) -> (A)

Q.2 - UGC NET DEC 2023

The selection of Spiral Model based on characteristics of requirements:
(A) Are requirements easily understandable and defined? (B) Do we change requirements quite
often? (C) Can we define requirements early in the cycle? (D) Requirements are indicating a
complex1 to be built
Choose the correct answer from the options given below:
i) (C) Only
ii) (B) Only
iii) (B) and (D) Only
iv) (A) and (C) Only

Q3. Which of these are the 5 generic software engineering framework activities?
[UGC NET June 2011]
a) Communication, planning, modelling, construction, deployment
b) Communication, risk management, measurement, production, reviewing
c) Analysis, designing, programming, debugging, maintenance
d) Analysis, planning, designing, programming, testing

Q4. Software does not wear out in the traditional sense of the term, but software does tend to
deteriorate as it evolves, because:
[UGC-NET CS 2017 Nov - II]
a) Software suffers from exposure to hostile environments.
b) Defects are more likely to arise after software has been used often.
c) Multiple change requests introduce errors in component interactions.
d) Software spare parts become harder to order.

Seshadri Rao Gudlavalleru Engineering College AS&A 2024-2025 Page 26

 R23 SOFTWARE ENGINEERING II [Link]

UNIT-2
SOFTWARE PROJECT MANAGEMENT
Syllabus:
Software Project Management: Software project management complexities,
Responsibilities of a software project manager, Metrics for project size estimation: Lines of
Code (LOC), Function Point (FP) Metric.
Project estimation techniques: Basic COCOMO, Intermediate COCOMO, Complete
COCOMO.
Risk management: Risk Identification, Risk Assessment, Risk Mitigation.
Requirements Analysis and Specification: Requirements Gathering and Analysis.
Software Requirements Specification (SRS): Users of SRS Document, Characteristics of a
Good SRS Document, Attributes of Bad SRS Documents, Important Categories of Customer
Requirements, Functional Requirements, How to Identify the Functional Requirements?,
How to Document the Functional Requirements?, organization of the SRS Document.

2. SOFTWARE PROJECT MANAGEMENT

 The main goal of software project management is to enable a group of developers to
work effectively towards the successful completion of a project.
 Effective project management is crucial to the success of any software development
project. In the past, several projects have failed not for want of competent technical
professionals neither for lack of resources, but due to the use of faulty project
management practices. Therefore, it is important to carefully learn the latest software
project management techniques.
2.1 Software Project Management Complexities
The main factors contributing to the complexity of managing a software project are the
following:
1. Invisibility:
 Software remains invisible, until its development is complete and it is
operational. Anything that is invisible is difficult to manage and control.
 Consider a house building project. For this project, the project manger can
very easily assess the progress of the project through a visual examination of
the building under construction. Therefore, the manager can closely monitor
the progress of the project, and take remedial actions whenever he finds that
the progress is not as per plan.
 In contrast, it becomes very difficult for the manager of a software project to
assess the progress of the project due to the invisibility of software. The best
that he can do perhaps is to monitor the milestones that have been completed
by the development team and the documents that have been produced—which
are rough indicators of the progress achieved.
 Invisibility of software makes it difficult to assess the progress of a project and
is a major cause for the complexity of managing a software project.

Seshadri Rao Gudlavalleru Engineering College AS &A 2024-25 Page 1

 R23 SOFTWARE ENGINEERING II [Link]

2. Changeability:
 Because the software part of any system is easier to change as compared to the
hardware part, the software part is the one that gets most frequently changed.
This is especially true in the later stages of a project.
 As far as hardware development is concerned, any late changes to the
specification of the hardware system under development usually amounts to
redoing the entire project. This makes late changes to a hardware project
prohibitively expensive to carry out. This possibly is a reason why
requirement changes are frequent in software projects. These changes usually
arise from changes to the business practices, changes to the hardware or
underlying software (e.g. operating system, other applications), or just because
the client changes his mind.
 Frequent changes to the requirements and the invisibility of software are
possibly the two major factors making software project management a
complex task.
3. Complexity:
 Even moderate sized software has millions of parts (functions) that interact
with each other in many ways—data coupling, serial and concurrent runs, state
transitions, control dependency, file sharing, etc.
 Due to the inherent complexity of the functioning of a software product in
terms of the basic parts making up the software, many types of risks are
associated with its development. This makes managing these projects much
more difficult as compared to many other kinds of projects.
4. Uniqueness:
 Every software project is usually associated with many unique features or
situations. This makes every project much different from the others. This is
unlike projects in other domains, such as car manufacturing or steel
manufacturing where the projects are more predictable.
 Due to the uniqueness of the software projects, a project manager in the course
of a project faces many issues that are quite unlike the others he had
encountered in the past. As a result, a software project manager has to confront
many unanticipated issues in almost every project that he manages.
5. Exactness of the solution:
 Mechanical components such as nuts and bolts typically work satisfactorily as
long as they are within a tolerance of 1 per cent or so of their specified sizes.
However, the parameters of a function call in a program are required to be in
complete conformity with the function definition.
 This requirement not only makes it difficult to get a software product up and
working, but also makes reusing parts of one software product in another
difficult. This requirement of exact conformity of the parameters of a function
introduces additional risks and contributes to the complexity of managing
software projects.
6. Team-oriented and intellect-intensive work:
 Software development projects are akin to research projects in the sense that
they both involve team-oriented, intellect-intensive work.

Seshadri Rao Gudlavalleru Engineering College AS &A 2024-25 Page 2

 R23 SOFTWARE ENGINEERING II [Link]

 In contrast, projects in many domains are labour-intensive and each member

works in a high degree of autonomy.
 Examples of such projects are planting rice, laying roads, assembly-line
manufacturing, constructing a multi-storeyed building, etc.
 In a software development project, the life cycle activities not only highly
intellectintensive, but each member has to typically interact, review, and
interface with several other members, constituting another dimension of
complexity of software projects.

2.2 Responsibilities of a software project manager:

2.2.1 Job Responsibilities for Managing Software Projects

 A software project manager takes the overall responsibility of steering a project to

success. This surely is a very hazy job description.
 In fact, it is very difficult to objectively describe the precise job responsibilities of a
project manager.
 The job responsibilities of a project manager range from invisible activities like
building up of team morale to highly visible customer presentations.
 Most managers take the responsibilities for project proposal writing, project cost
estimation, scheduling, project staffing, software process tailoring, project monitoring
and control, software configuration management, risk management, managerial report
writing and presentation, and interfacing with clients. These activities are certainly
numerous and varied.
 Broadly classify a project manager’s varied responsibilities into the following two
major categories:
o Project planning, and
o Project monitoring and control.

Project planning:
 Project planning is undertaken immediately after the feasibility study phase and
before the starting of the requirements analysis and specification phase.
 Project planning involves estimating several characteristics of a project and then
planning the project activities based on these estimates made.
 The initial project plans are revised from time to time as the project progresses and
more project data become available.
Project monitoring and control:
 Project monitoring and control activities are undertaken once the development
activities start.
 The focus of project monitoring and control activities is to ensure that the software
development proceeds as per plan.
 While carrying out project monitoring and control activities, a project manager may
sometimes find it necessary to change the plan to cope up with specific situations at
hand.

Seshadri Rao Gudlavalleru Engineering College AS &A 2024-25 Page 3

 R23 SOFTWARE ENGINEERING II [Link]

2.2.2 Skills Necessary for Managing Software Projects

 A theoretical knowledge of various project management techniques is certainly
important to become a successful project manager.
 However, a purely theoretical knowledge of various project management techniques
would hardly make one a successful project manager.
 Effective software project management calls for good qualitative judgment and
decision taking capabilities.
 In addition to having a good grasp of the latest software project management
techniques such as cost estimation, risk management, and configuration management,
etc., project managers need good communication skills and the ability to get work
done.
 Some skills such as tracking and controlling the progress of the project, customer
interaction, managerial presentations, and team building are largely acquired through
experience. Never the less, the importance of a sound knowledge of the prevalent
project management techniques cannot be overemphasized.
 Three skills that are most critical to successful project management are the following:
a) Knowledge of project management techniques.
b) Decision taking capabilities.
c) Previous experience in managing similar projects.

2.3 METRICS FOR PROJECT SIZE ESTIMATION:

The project size is a measure of the problem complexity in terms of the effort and time
required to develop the product.
Currently, two metrics are popularly being used to measure size

 Lines of code (LOC)

 Function point (FP).
2.3.1 Lines of Code (LOC)
 LOC is possibly the simplest among all metrics available to measure project size.
 This metric measures the size of a project by counting the number of source
instructions in the developed program. Obviously, while counting the number of
source instructions, comment lines, and header lines are ignored.
 Determining the LOC count at the end of a project is very simple. However, accurate
estimation of LOC count at the beginning of a project is a very difficult task.
 One can possibly estimate the LOC count at the starting of a project, only by using
some form of systematic guess work.
 Systematic guessing typically involves the following. The project manager divides the
problem into modules, and each module into sub-modules and so on, until the LOC of
the leaf-level modules are small enough to be predicted.
 To be able to predict the LOC count for the various leaf-level modules sufficiently
accurately, past experience in developing similar modules is very helpful.
 By adding the estimates for all leaf level modules together, project managers arrive at
the total size estimation.

Seshadri Rao Gudlavalleru Engineering College AS &A 2024-25 Page 4

 R23 SOFTWARE ENGINEERING II [Link]

Shortcomings of the LOC metric.

1. LOC is a measure of coding activity alone.
 A good problem size measure should consider the total effort needed to carry
out various life cycle activities (i.e. specification, design, code, test, etc.) and
not just the coding effort. LOC, however, focuses on the coding activity
alone—it merely computes the number of source lines in the final program.
 The presumption that the total effort needed to develop a project is
proportional to the coding effort is easily countered by noting the fact that
even when the design or testing issues are very complex, the code size might
be small and vice versa.
 Thus, the design and testing efforts can be grossly disproportional to the
coding effort. Code size, therefore, is obviously an improper indicator of the
problem size.
2. LOC count depends on the choice of specific instructions:
 LOC gives a numerical value of problem size that can vary widely with coding
styles of individual programmers.
 By coding style, we mean the choice of code layout, the choice of the
instructions in writing the program, and the specific algorithms used.
 Different programmers may lay out their code in very different ways. For
example, one programmer might write several source instructions on a single
line, whereas another might split a single instruction across several lines.
Unless this issue is handled satisfactorily, there is a possibility of arriving at
very different size measures for essentially identical programs.
 Even for the same programming problem, different programmers might come
up with programs having very different LOC counts. This situation does not
improve, even if language tokens are counted instead of lines of code.
3. LOC measure correlates poorly with the quality and efficiency of the code:
 Larger code size does not necessarily imply better quality of code or higher
efficiency. Some programmers produce lengthy and complicated code as they
do not make effective use of the available instruction set or use improper
algorithms.
 Calculating productivity as LOC generated per man-month may encourage
programmers to write lots of poor quality code rather than fewer lines of high
quality code achieve the same functionality.
4. LOC metric penalises use of higher-level programming languages and code
reuse:
 A paradox is that if a programmer consciously uses several library routines,
then the LOC count will be lower.
 This would show up as smaller program size, and in turn, would indicate
lower effort! Thus, if managers use the LOC count to measure the effort put in
by different developers (that is, their productivity), they would be
discouraging code reuse by developers.
 Modern programming methods such as object-oriented programming and
reuse of components makes the relationships between LOC and other project
attributes even less precise.

Seshadri Rao Gudlavalleru Engineering College AS &A 2024-25 Page 5

 R23 SOFTWARE ENGINEERING II [Link]

5. LOC metric measures the lexical complexity of a program and does not address
the more important issues of logical and structural complexities:
 Between two programs with equal LOC counts, a program incorporating
complex logic would require much more effort to develop than a program with
very simple logic.
 To realise why this is so, imagine the effort that would be required to develop
a program having multiple nested loops and decision constructs and compare
that with another program having only sequential control flow.
6. It is very difficult to accurately estimate LOC of the final program from problem
specification:
 At the project initiation time, it is a very difficult task to accurately estimate
the number of lines of code (LOC) that the program would have after
development.
 The LOC count can accurately be computed only after the code has fully been
developed.
 Since project planning is carried out even before any development activity
starts, the LOC metric is of little use to the project managers during project
planning.
From the project manager’s perspective, the biggest shortcoming of the LOC metric is that
the LOC count is very difficult to estimate during project planning stage, and can only be
accurately computed after the software development is complete.
2.3.2 Function Point (FP) Metric
 Function point metric was proposed by Albrecht in 1983.
 This metric overcomes many of the shortcomings of the LOC metric.
 The conceptual idea behind the function point metric is the following.
 The size of a software product is directly dependent on the number of different
high-level functions or features it supports. This assumption is reasonable,
since each feature would take additional effort to implement.
 Though each feature takes some effort to develop, different features may take very
different amounts of efforts to develop.
 For example, in banking software, a function to display a help message may be much
easier to develop compared to say the function that carries out the actual banking
transactions.
 This has been considered by the function point metric by counting the number of
input and output data items and the number of files accessed by the function.
 The implicit assumption made is that the more the number of data items that a
function reads from the user and outputs and the more the number of files accessed,
the higher is the complexity of the function.
 Now let us analyse why this assumption must be intuitively correct. Each feature
when invoked typically reads some input data and then transforms those to the
required output data.
 For example, the query book feature (see Figure below) of a Library Automation
Software takes the name of the book as input and displays its location in the library
and the total number of copies available.

Seshadri Rao Gudlavalleru Engineering College AS &A 2024-25 Page 6

 R23 SOFTWARE ENGINEERING II [Link]

 Similarly, the issue book and the return book features produce their output based on
the corresponding input data. It can therefore be argued that the computation of the
number of input and output data items would give a more accurate indication of the
code size compared to simply counting the number of high-level functions supported
by the system.

Figure: System function as a mapping of input data to output data.

 Albrecht postulated that in addition to the number of basic functions that a software
performs, size also depends on the number of files and the number of interfaces that
are associated with the software.
 Here, interfaces refer to the different mechanisms for data transfer with external
systems including the interfaces with the user, interfaces with external computers, etc.
Function point (FP) metric computation
It is computed using the following three steps:
Step 1: Compute the unadjusted function point (UFP)
Step 2: Refine UFP
Step 3: Compute FP by further refining UFP
Step 1: UFP computation
The unadjusted function points (UFP) is computed as the weighted sum of five characteristics
of a product
a) Number of inputs: Each data item input by the user is counted.
b) Number of outputs: The outputs considered include reports printed, screen
outputs, error messages produced, etc.
c) Number of inquiries: An inquiry is a user command (without any data input)
and only requires some actions to be performed by the system.
d) Number of files: The files are logical files.
e) Number of interfaces: The interfaces denote the different mechanisms that
are used to exchange information with other systems. Examples of such
interfaces are data files on tapes, disks, communication links with other
systems, etc.

Seshadri Rao Gudlavalleru Engineering College AS &A 2024-25 Page 7

 R23 SOFTWARE ENGINEERING II [Link]

Step 2: Refine parameters

• UFP computed at the end of step 1 is a gross indicator of the problem size. This UFP
needs to be refined.
• For example, some input values may be extremely complex, some very simple, etc.
• The complexity of each parameter is graded into three broad categories—simple,
average, or complex.
• The weights for the different parameters are determined based on the numerical
values.

Step 3: Refine UFP based on complexity of the overall project

• In the final step, several factors that can impact the overall project size are considered
to refine the UFP computed in step 2.
• Albrecht identified 14 parameters that can influence the development effort.

Seshadri Rao Gudlavalleru Engineering College AS &A 2024-25 Page 8

 R23 SOFTWARE ENGINEERING II [Link]

• Each of these 14 parameters is assigned a value from 0 (not present or no influence) to

6 (strong influence).
• 0 ( not present)
• 1 (incidental)
• 2 (moderate)
• 3 (average)
• 4 (significant)
• 5 (highly essential)
• 6 (strong influence)
• The resulting numbers are summed, yielding the total degree of influence (DI).
• A Technical Complexity Factor (TCF) for the project is computed and the TCF is
multiplied with UFP to yield FP.
• The TCF expresses the overall impact of the corresponding project parameters on the
development effort.
• TCF is computed as (0.65+0.01*DI).
• As DI can vary from 0 to 84, TCF can vary from 0.65 to 1.49.
• Finally, FP is given as the product of UFP and TCF.
FP=UFP*TCF
Example 1:
Compute the FP value for the grade calculation of students. Assume that it is an average
complexity size project. The information domain values are as follows:
Number of user inputs = 13
Number of user outputs = 4

Seshadri Rao Gudlavalleru Engineering College AS &A 2024-25 Page 9

 R23 SOFTWARE ENGINEERING II [Link]

Number of user inquiries = 2

Number of files = 5
Number of external interfaces = 2
The total value of complexity adjustment attribute is 13.
Solution:

Domain Weighting factor

Characteristics Count Count
Simple Average Complex

No of user Input 13 * 3 4 6 52

No of user output 4 * 4 5 7 20

No of user 2 * 3 4 6 8
enquiries

No of files 5 * 7 10 15 50

No of external 2 * 5 7 10 14
interfaces

UFP value : 144

• Compute TCF , which has the CAA value = 13

• DI=13*3=39
TCF=0.65+0.01*(DI) = 0.65+0.01*39 = 1.04
• compute FP = UFP * TCF
• =144*1.04
= 149.76
Example 2: Compute the FP value for an average complexity size project. The information
domain values are as follows:
Number of user inputs = 50
Number of user outputs = 40
Number of user inquiries = 35
Number of files = 6
Number of external interfaces = 4
The total value of complexity adjustment attribute is 14.

Seshadri Rao Gudlavalleru Engineering College AS &A 2024-25 Page 10

 R23 SOFTWARE ENGINEERING II [Link]

Solution:

Domain Weighting factor

Characteristics Count Count
Simple Average Complex

No of user Input 50 * 3 4 6 200

No of user output 40 * 4 5 7 200

No of user 35 * 3 4 6 140
enquiries

No of files 6 * 7 10 15 60

No of external 4 * 5 7 10 28
interfaces

UFP value : 628

• Compute TCF , which has the CAA value = 14

• DI=14*3=42
TCF=0.65+0.01*(DI) = 0.65+0.01*42 = 1.07
• compute FP = UFP * TCF
• =628*1.07
= 671.96
Example 3 Determine the function point measure of the size of the following supermarket
software. A supermarket needs to develop the following software to encourage regular
customers. For this, the customer needs to supply his/her residence address, telephone
number, and the driving license number. Ea ch customer who registers for this scheme is
assigned a unique customer number (CN) by the computer. Based on the generated CN, a
clerk manually prepares a customer identity card after getting the market manager’s signature
on it. A customer can present his customer identity card to the check out staff when he makes
any purchase. In this case, the value of his purchase is credited against his CN. At the end of
each year, the supermarket intends to award surprise gifts to 10 customers who make the
highest total purchase over the year. Also, it intends to award a 22 carat gold coin to every
customer whose purchase exceeded Rs. 10,000. The entries against the CN are reset on the
last day of every year after the prize winners’ lists are generated. Assume that various project
characteristics determining the complexity of software development to be average.
Solution:
Step 1: From an examination of the problem description, we find that there are two inputs,
three outputs, two files, and no interfaces. Two files would be required, one for storing the

Seshadri Rao Gudlavalleru Engineering College AS &A 2024-25 Page 11

 R23 SOFTWARE ENGINEERING II [Link]

customer details and another for storing the daily purchase records. Now, using equation 3.1,
we get:
UFP = 2 × 4 + 3 × 5 + 1 × 4 + 10 × 2 + 0 × 10 = 47
Step 2: Al l the parameters are of moderate complexity, except the output parameter of
customer registration, in which the only output is the CN value. Consequently, the complexity
of the output parameter of the customer registration function can be categorized as simple. By
consulting Table 3.1, we find that the value for simple output is given to be 4.
The UFP can be refined as follows:
UFP = 3 × 4 + 2 × 5 + 1 × 4 + 10 × 2 + 0 × 10 = 46.
Step 3: Since the complexity adjustment factors have average values, therefore the total
degrees of influence would be: DI = 14 × 4 = 56 TCF = 0.65 + 0.01 + 56 = 1.21 Therefore,
the adjusted FP=46*1.21=55.66.
Function point metric shortcomings:
 A major shortcoming of the function point measure is that it does not take into
account the algorithmic complexity of a function.
 That is, the function point metric implicitly assumes that the effort required to design
and develop any two different functionalities of the system is the same.
 The effort required to develop any two functionalities may vary widely.
 For example, in a library automation software, the create-member feature would be
much simpler compared to the loan-from-remote-library feature. FP only considers
the number of functions that the system supports, without distinguishing the difficulty
levels of developing the various functionalities.
 To overcome this problem, an extension to the function point metric called feature
point metric has been proposed. Feature point metric incorporates algorithm
complexity as an extra parameter.
 This parameter ensures that the computed size using the feature point metric reflects
the fact that higher the complexity of a function, the greater the effort required to
develop it—therefore, it should have larger size compared to a simpler function.
Critical comments on the function point and feature point metrics
 Proponents of function point and feature point metrics claim that these two metrics
are language-independent and can be easily computed from the SRS document during
project planning stage itself.
 On the other hand, opponents claim that these metrics are subjective and require a
sleight of hand.
 An example of the subjective nature of the function point metric can be that the way
one groups input and output data items into logically related groups can be very
subjective.
 For example, consider that certain functionality requires the employee name and
employee address to be input. It is possible that one can consider both these items as a
single unit of data, since after all, these describe a single employee. It is also possible
for someone else to consider an employee’s address as a single unit of input data and

Seshadri Rao Gudlavalleru Engineering College AS &A 2024-25 Page 12

 R23 SOFTWARE ENGINEERING II [Link]

name as another. Such ambiguities leave sufficient scope for debate and keep open the
possibility for different project managers to arrive at different function point measures
for essentially the same problem.
2.4 PROJECT ESTIMATION TECHNIQUES
 Estimation of various project parameters is an important project planning activity.
 The different parameters of a project that need to be estimated include—project size,
effort required to complete the project, project duration, and cost.
 Accurate estimation of these parameters is important, since these not only help in
quoting an appropriate project cost to the customer, but also form the basis for
resource planning and scheduling.
 These can broadly be classified into three main categories:
a) Empirical estimation techniques
b) Heuristic techniques
c) Analytical estimation techniques
The Constructive Cost Model (COCOMO) - A HEURISTIC ESTIMATION
TECHNIQUE
Constructive Cost model (COCOMO)

Intermediate Detailed or Complete

Basic

Model proposed by B. W. Boehm’s in 1981

COCOMO applied to
1. Organic mode
2. Semidetached mode
3. Embedded mode

Seshadri Rao Gudlavalleru Engineering College AS &A 2024-25 Page 13

 R23 SOFTWARE ENGINEERING II [Link]

Mode Project size Nature of Project Innovation Deadline of Development

the project Environment

Organic Typically Small size project, experienced Little Not tight Familiar & In
developers in the familiar house
2-50 KLOC
environment. For example, pay
roll, inventory projects etc.

Semi Typically Medium size project, Medium Medium Medium Medium

detached size team, Average previous
50-300 KLOC
experience on similar project.
For example: Utility systems
like compilers, database
systems, editors etc.

Embedded Typically over Large project, Real time Significant Tight Complex
systems, Complex interfaces, Hardware/
300 KLOC
Very little previous experience. customer
For example: ATMs, Air Traffic Interfaces
Control etc. required

Basic COCOMO Model

The basic COCOMO estimation model is given by following expressions
• Effort = a1 × (KLOC)a2 PM
• Tdev = b1 × (Effort)b2 months
Where, KLOC is the estimated size of the software product expressed in Kilo Lines of Code.
a1, a2, b1, b2 are constants for each category of software product.
Effort is the total effort required to develop the software product, expressed in person-
months (PMs).
Tdev is the estimated time to develop the software, expressed in months.
Person-month (PM) is a popular unit for effort measurement.
Person-month (PM) is considered to be an appropriate unit for measuring effort, because
developers are typically assigned to a project for a certain number of months.

a1 a2 b1 b2
Organic 2.4 1.05 2.5 0.38

Semi- 3.0 1.12 2.5 0.35

detached
Embedded 3.6 1.20 2.5 0.32

Estimation of effort:
• Organic : Effort = 2.4(KLOC)1.05 PM
• Semi-detached : Effort = 3.0(KLOC)1.12 PM

Seshadri Rao Gudlavalleru Engineering College AS &A 2024-25 Page 14

 R23 SOFTWARE ENGINEERING II [Link]

• Embedded : Effort = 3.6(KLOC)1.20 PM

Estimation of development time
• Organic : Tdev = 2.5(Effort)0.38 Months
• Semi-detached : Tdev = 2.5(Effort)0.35 Months
• Embedded : Tdev = 2.5(Effort)0.32 Months
Example:1
Assume that a system for simple student registration in a course is planned to be developed
and its estimated size is approximately 10,000 LOC. The organization proposed to pay
25,000 per month to s/w engineers. Compute the development effort, development time, and
the total cost for product development.
Solution:
• The project can be considered an organic project.
• From basic COCOMO Model
• Development effort (E)=2.4*(10)1.05=26.93PM
• Development effort (T)=2.5*(26.93)0.38=8.74months
• Total product development cost=Development time *salaries of engineers
=8.74*25000
=2,18,500/-
Intermediate COCOMO
 The basic COCOMO model determines the effort and time based on the project size.
 There are certain other factors that can affect the project size and hence the
development effort and time.
 Therefore, Boehm has introduced 15 cost drivers, considering the various aspects of
product development environment.
 These cost drivers are used to adjust the project complexity and are termed as effort
adjustment factors (EAF).
 These cost drivers are classified as Computer Attributes, Product Attributes, Project
Attributes, and Personnel Attributes.
 The Intermediate COCOMO model computes software development effort as a
function of the program size and a set of cost drivers. The cost drivers and their
ratings are shown in Table

Seshadri Rao Gudlavalleru Engineering College AS &A 2024-25 Page 15

 R23 SOFTWARE ENGINEERING II [Link]

 The intermediate COCOMO model estimates the initial effort using the basic
COCOMO model
 Then the EAF is calculated as the product of 15 cost drivers.
 Total effort is determined by multiplying the initial effort with the total value of EAF.
 The computation steps are summarized below

a1 a2 b1 b2
Organic 3.2 1.05 2.5 0.38

Semi- 3.0 1.12 2.5 0.35

detached
Embedded 3.6 1.20 2.5 0.32

• Development effort (E):

• Initial effort (Ei) = a1 × (KLOC) a2
• Effort Adjustment Factor (EAF) = EAF1× EAF2×... × EAFn
• Total development effort (E) = Ei× EAF
• Development time (T) = b1 × (E)b2
Example:
Suppose a lib management system (LMS) is to be designed for an academic institution.
From the project proposal, the following five major components are identified:
online data entry - 1.0 kloc
data update - 2.0 kloc

Seshadri Rao Gudlavalleru Engineering College AS &A 2024-25 Page 16

 R23 SOFTWARE ENGINEERING II [Link]

file input and output - 1.5 kloc

library reports - 2.0 kloc
query and search - 0.5 kloc
The database size and application experience are very important in this project. The use of the
software tool and the main storage is highly considerable. The virtual machine experience
and its volatility can be kept low. All other cost drivers have nominal requirements. Use the
COCOMO model to estimate the development effort and the development time

Detailed COCOMO Model

 The detailed COCOMO inherits all the features of the intermediate COCOMO model
for the overall estimation of the project cost.
 For detailed planning and scheduling, it is necessary to assess the impact of the cost
drivers in a phased manner.
 The detailed COCOMO model uses different cost drivers for each phase of the
project. Phase-wise effort multipliers provide better estimates than the intermediate
model.
 The detailed COCOMO model defines five life cycle phases for effort distribution:
 Plan and Requirement,
 System Design,
 Detailed Design,
 Code and Unit Test, and
 Integration Test.

Seshadri Rao Gudlavalleru Engineering College AS &A 2024-25 Page 17

 R23 SOFTWARE ENGINEERING II [Link]

Seshadri Rao Gudlavalleru Engineering College AS &A 2024-25 Page 18

 R23 SOFTWARE ENGINEERING II [Link]

2.5 RISK MANAGEMENT:

 A risk is any anticipated unfavourable event or circumstance that can occur while a
project is underway.
 It is necessary for the project manager to anticipate and identify different risks that a
project is susceptible to, so that contingency plans can be prepared beforehand to
contain each risk.
 In this context, risk management aims at reducing the chances of a risk becoming real
as well as reducing the impact of risks that becomes real.
 Risk management consists of three essential activities
 Risk identification,
 Risk assessment, and
 Risk mitigation.

2.5.1 Risk Identification

 The project manager needs to anticipate the risks in a project as early as possible. As
soon as a risk is identified, effective risk management plans are made, so that the
possible impacts of the risks is minimised. So, early risk identification is important.
 Risk identification is somewhat similar to the project manager listing down his
nightmares. For example, project manager might be worried whether the vendors
whom you have asked to develop certain modules might not complete their work in
time, whether they would turn in poor quality work, whether some of your key
personnel might leave the organisation, etc. All such risks that are likely to affect a
project must be identified and listed
 A project can be subject to a large variety of risks. In order to be able to
systematically identify the important risks which might affect a project, it is necessary
to categorise risks into different classes.
 The project manager can then examine which risks from each class are relevant to the
project. There are three main categories of risks which can affect a software project:
project risks, technical risks, and business risks. We discuss these risks in the
following.
 Project risks:
 Project risks concern various forms of budgetary, schedule,
personnel, resource, and customer-related problems. An
important project risk is schedule slippage.

Seshadri Rao Gudlavalleru Engineering College AS &A 2024-25 Page 19

 R23 SOFTWARE ENGINEERING II [Link]

 Since, software is intangible, it is very difficult to monitor and

control a software project. It is very difficult to control
something which cannot be seen.
 The invisibility of the product being developed is an important
reason why many software projects suffer from the risk of
schedule slippage.
 Technical risks:
 Technical risks concern potential design, implementation,
interfacing, testing, and maintenance problems.
 Technical risks also include ambiguous specification,
incomplete specification, changing specification, technical
uncertainty, and technical obsolescence.
 Most technical risks occur due the development team’s
insufficient knowledge about the product.
 Business risks:
 This type of risks includes the risk of building an excellent
product that no one wants, losing budgetary commitments, etc.
Example: consider a satellite based mobile communication product, the project manager can
identify several risks in this project.
a. What if the project cost escalates and overshoots what was estimated?:
Project risk.
b. What if the mobile phones that are developed become too bulky in size to
conveniently carry?: Business risk.
c. What if it is later found out that the level of radiation coming from the phones
is harmful to human being?: Business risk.
d. What if call hand-off between satellites becomes too difficult to implement?:
Technical risk.
In order to be able to successfully foresee and identify different risks that might affect a
software project, it is a good idea to have a company disaster list. This list would contain all
the bad events that have happened to software projects of the company over the years
including events that can be laid at the customer’s doors. This list can be read by the project
managers in order to be aware of some of the risks that a project might be susceptible to.
Such a disaster list has been found to help in performing better risk analysis.
2.5.2 Risk Assessment
The objective of risk assessment is to rank the risks in terms of their damage causing
potential. For risk assessment, first each risk should be rated in two ways:
 The likelihood of a risk becoming real (r).
 The consequence of the problems associated with that risk (s).
Based on these two factors, the priority of each risk can be computed as follows: p = r x s
where, p is the priority with which the risk must be handled, r is the probability of the risk
becoming real, and s is the severity of damage caused due to the risk becoming real. If all

Seshadri Rao Gudlavalleru Engineering College AS &A 2024-25 Page 20

 R23 SOFTWARE ENGINEERING II [Link]

identified risks are prioritised, then the most likely and damaging risks can be handled first
and more comprehensive risk abatement procedures can be designed for those risks.

2.5.3 Risk Mitigation

 After all the identified risks of a project have been assessed, plans are made to contain
the most damaging and the most likely risks first.
 Different types of risks require different containment procedures. In fact, most risks
require considerable ingenuity on the part of the project manager in tackling the risks.

There are three main strategies for risk containment:

1. Avoid the risk: Risks can be avoided in several ways. Risks often arise due to project
constraints and can be avoided by suitably modifying the constraints. The different categories
of constraints that usually give rise to risks are:

a. Process-related risk: These risks arise due to aggressive work schedule, budget, and
resource utilisation.

b. Product-related risks: These risks arise due to commitment to challenging product

features (e.g. response time of one second, etc.), quality, reliability etc.

c. Technology-related risks: These risks arise due to commitment to use certain

technology (e.g., satellite communication).

d. Transfer the risk: This strategy involves getting the risky components developed by
a third party, buying insurance cover, etc.

2. Risk reduction:
 This involves planning ways to contain the damage due to a risk. For example, if there
is risk that some key personnel might leave, new recruitment may be planned. The
most important risk reduction techniques for technical risks are to build a prototype
that tries out the technology that you are trying to use.
 For example, if you are using a compiler for recognising user commands, you would
have to construct a compiler for a small and very primitive command language first
 There can be several strategies to cope up with a risk. To choose the most appropriate
strategy for handling a risk, the project manager must consider the cost of handling
the risk and the corresponding reduction of risk.
 For this we may compute the risk leverage of the different risks. Risk leverage is the
difference in risk exposure divided by the cost of reducing the risk. More formally,

 Even though we identified three broad ways to handle any risk, effective risk handling
cannot be achieved by mechanically following a set procedure, but requires a lot of
ingenuity on the part of the project manager.

Seshadri Rao Gudlavalleru Engineering College AS &A 2024-25 Page 21

 R23 SOFTWARE ENGINEERING II [Link]

Boehm’s Top 10 Risks and Counter Measures

Risk Management Plan for a project:

Seshadri Rao Gudlavalleru Engineering College AS &A 2024-25 Page 22

 R23 SOFTWARE ENGINEERING II [Link]

2.6 REQUIREMENTS ANALYSIS AND SPECIFICATION

Overview:
 The requirements analysis and specification phase starts after the feasibility study
stage is complete and the project has been found to be financially viable and
technically feasible.
 The requirements analysis and specification phase ends when the requirements
specification document has been developed and reviewed.
 The requirements specification document is usually called as the software
requirements specification (SRS) document.
Who carries out requirements analysis and specification?
 Requirements analysis and specification activity is usually carried out by a few
experienced members of the development team and it normally requires them to spend
some time at the customer site.
 The engineers who gather and analyse customer requirements and then write the
requirements specification document are known as system analysts in the software
industry parlance.
 System analysts collect data pertaining to the product to be developed and analyse the
collected data to conceptualise what exactly needs to be done. After understanding the
precise user requirements, the analysts analyse the requirements to weed out
inconsistencies, anomalies and incompleteness. They then proceed to write the
software requirements specification (SRS) document.
 The SRS document is the final outcome of the requirements analysis and specification
phase.
How is the SRS document validated?
 Once the SRS document is ready, it is first reviewed internally by the project team to
ensure that it accurately captures all the user requirements, and that it is
understandable, consistent, unambiguous, and complete.
 The SRS document is then given to the customer for review. After the customer has
reviewed the SRS document and agrees to it, it forms the basis for all future
development activities and also serves as a contract document between the customer
and the development organisation.
What are the main activities carried out during requirements analysis and specification
phase?
Requirements analysis and specification phase mainly involves carrying out the following
two important activities:
• Requirements gathering and analysis
• Requirements specification

Seshadri Rao Gudlavalleru Engineering College AS &A 2024-25 Page 23

 R23 SOFTWARE ENGINEERING II [Link]

2.6.1 REQUIREMENTS GATHERING AND ANALYSIS

[Link] Requirements Gathering
 Requirements gathering are also popularly known as requirements elicitation.
 The primary objective of the requirements gathering task is to collect the requirements
from the stakeholders.
 A stakeholder is a source of the requirements and is usually a person, or a group of
persons who either directly or indirectly are concerned with the software.
The important ways in which an experienced analyst gathers requirements:
1. Studying existing documentation: The analyst usually studies all the available
documents regarding the system to be developed before visiting the customer site.
2. Interview: Typically, there are many different categories of users of a software. Each
category of users typically requires a different set of features from the software.
Therefore, it is important for the analyst to first identify the different categories of
users and then determine the requirements of each.
3. Task analysis: The analyst tries to identify and understand the different tasks to be
performed by the software. For each identified task, the analyst tries to formulate the
different steps necessary to realise the required functionality in consultation with the
users.
4. Scenario analysis: A task can have many scenarios of operation. The different
scenarios of a task may take place when the task is invoked under different situations.
5. Form analysis: In form analysis the exiting forms and the formats of the notifications
produced are analysed to determine the data input to the system and the data that are
output from the system.

[Link] Requirements Analysis:

• After requirements gathering is complete, the analyst analyses the gathered
requirements to form a clear understanding of the exact customer requirements and to
weed out any
• The main purpose of the requirements analysis activity is to analyse the gathered
requirements to remove all ambiguities, incompleteness, and inconsistencies from the
gathered customer requirements and to obtain a clear understanding of the software to
be developed. Problems in the gathered requirements.
• The following basic questions pertaining to the project should be clearly understood
by the analyst before carrying out analysis:
1. What is the problem?
2. Why is it important to solve the problem?
3. What exactly are the data input to the system and what exactly are the
data output by the system?
4. What are the possible procedures that need to be followed to solve the
problem?

Seshadri Rao Gudlavalleru Engineering College AS &A 2024-25 Page 24

 R23 SOFTWARE ENGINEERING II [Link]

5. What are the likely complexities that might arise while solving the
problem?
6. If there are external software or hardware with which the developed
software has to interface, then what should be the data interchange formats
with the external systems?
During requirements analysis, the analyst needs to identify and resolve three main types
of problems in the requirements:
• Anomaly
• Inconsistency
• Incompleteness
Anomaly: Anomaly is an ambiguity in a requirement. When a requirement is
anomalous, several interpretations of that requirement are possible.
Inconsistency: Two requirements are said to be inconsistent, if one of the
requirements contradicts the other.
Incompleteness: An incomplete set of requirements is one in which some
requirements have been overlooked. An experienced analyst can detect most of these
missing features and suggest them to the customer
2.7 SOFTWARE REQUIREMENTS SPECIFICATION (SRS)
• After the analyst has gathered all the required information regarding the software to
be developed, and has removed all incompleteness, inconsistencies, and anomalies
from the specification, developer systematically organise the requirements in the form
of an SRS document.
• Among all the documents produced during a software development life cycle, SRS
document is probably the most important document and is the toughest to write.
• SRS document as the documentation of a contract between the development team and
the customer
2.7.1 Users of SRS Document
1. Users, customers, and marketing personnel: These stakeholders need to refer to the
SRS document to ensure that the system as described in the document will meet their
needs. Remember that the customer may not be the user of the software, but may be
someone employed or designated by the user .
2. Software developers: The software developers refer to the SRS document to make
sure that they are developing exactly what is required by the customer.
3. Test engineers: The test engineers use the SRS document to understand the
functionalities, and based on this write the test cases to validate its working. They
need that the required functionality should be clearly described, and the input and
output data should have been identified precisely.

Seshadri Rao Gudlavalleru Engineering College AS &A 2024-25 Page 25

 R23 SOFTWARE ENGINEERING II [Link]

4. User documentation writers: The user documentation writers need to read the SRS
document to ensure that they understand the features of the product well enough to be
able to write the users’ manuals.
5. Project managers: The project managers refer to the SRS document to ensure that
they can estimate the cost of the project easily by referring to the SRS document and
that it contains all the information required to plan the project.
6. Maintenance engineers: The SRS document helps the maintenance engineers to
under- stand the functionalities supported by the system. A clear knowledge of the
functionalities can help them to understand the design and code.
2.7.2 Characteristics of a Good SRS Document
 The skill of writing a good SRS document usually comes from the
experience gained from writing SRS documents for many projects.
 IEEE Recommended Practice for Software Requirements
Specifications[IEEE830] describes the content and qualities of a good
software requirements specification (SRS).
1. Concise: The SRS document should be concise and at the same time unambiguous,
consistent, and complete.
2. Implementation-independent: The SRS should be free of design and
implementation decisions unless those decisions reflect actual requirements. It
should only specify what the system should do and refrain from stating how to do
these.
The SRS document should describe the system to be developed as a black box, and
should specify only the externally visible behaviour of the system. For this reason,
the SRS document is also called the black-box specification of the software being
developed.

Figure: The black-box view of a system as performing a set of functions.

3. Traceable: It should be possible to trace a specific requirement to the design elements that
implement it and vice versa. Traceability is also important to verify the results of a phase with
respect to the previous phase and to analyse the impact of changing a requirement on the
design elements and the code.

4. Modifiable: Customers frequently change the requirements during the software

development due to a variety of reasons. An SRS document is often modified after the project

Seshadri Rao Gudlavalleru Engineering College AS &A 2024-25 Page 26

 R23 SOFTWARE ENGINEERING II [Link]

completes to accommodate future enhancements and evolution. A wellstructured document is

easy to understand and modify. But it become difficult as it would require changes to be made
at large number of places in the document.

5. Identification of response to undesired events: The SRS document should discuss the
system responses to various undesired events and exceptional conditions that may arise.

6. Verifiable: All requirements of the system as documented in the SRS document should be
verifiable. This means that it should be possible to design test cases based on the description
of the functionality as to whether or not requirements have been met in an implementation.
Any feature of the required system that is not verifiable should be listed separately in the
goals of the implementation section of the SRS document.

2.7.3 Attributes of Bad SRS documents

SRS documents written by novices frequently suffer from a variety of problems. Some of the
problems are

a. Over-specification: It occurs when the analyst tries to address the “how to” aspects in
the SRS document. For example, in the library automation problem, one should not
specify whether the library membership records need to be stored indexed on the
member’s first name or on the library member’s identification (ID) number. Over-
specification restricts the freedom of the designers in arriving at a good design
solution.
b. Forward references: One should not refer to aspects that are discussed much later in
the SRS document. Forward referencing seriously reduces readability of the
specification.
c. Wishful thinking: This type of problems concern description of aspects which would
be difficult to implement.
d. Noise: The term noise refers to presence of material not directly relevant to the
software development process.

2.7.4 Important categories of customer Requirements

A good SRS document should properly categorize and organise the requirements into
different sections [IEEE830].

As per the IEEE 830 guidelines, the important categories of user requirements are the
following.

An SRS document should clearly document the following aspects of software:

1. Functional requirements
2. Non-functional requirements
a. Design and implementation constraints
b. External interfaces required
c. Other non-functional requirements
3. Goals of implementation.

Seshadri Rao Gudlavalleru Engineering College AS &A 2024-25 Page 27

 R23 SOFTWARE ENGINEERING II [Link]

1. Functional requirements

• The functional requirements capture the functionalities required by the users from the
system.
• Consider a software as offering a set of functions {fi} to the user.
• These functions can be considered similar to a mathematical function f: I → O,
meaning that a function transforms an element (ii) in the input domain (I) to a value
(oi) in the output.
• Each function fi of the system can be considered as reading certain data ii, and then
transforming a set of input data (ii) to the corresponding set of output data (oi).
• The functional requirements of the system, should clearly describe each functionality
that the system would support along with the corresponding input and output data set.

2. Non-functional requirements

• The non-functional requirements are non-negotiable obligations that must be

supported by the software.
• The non-functional requirements capture those requirements of the customer that
cannot be expressed as functions
• Non-functional requirements usually address external interfaces, user interfaces,
maintainability, portability, usability, maximum number of concurrent users, timing,
and throughput (transactions per second, etc.).
• The non-functional requirements can be critical in the sense that any failure by the
developed software to achieve some minimum defined level in these requirements can
be considered as a failure and make the software unacceptable by the customer.
• The IEEE 830 standard recommends that out of the various non-functional
requirements, the external interfaces, and the design and implementation constraints
should be documented in two different sections.
• The remaining non-functional requirements should be documented later in a section
and these should include the performance and security requirements.

a) Design and implementation constraints:

• Design and implementation constraints are an important category of non-functional

requirements describe any items or issues that will limit the options available to the
developers.
• Some of the example constraints can be—corporate or regulatory policies that needs
to be honoured; hardware limitations; interfaces with other applications; specific
technologies, tools, and databases to be used; specific communications protocols to be
used; security considerations; design conventions or programming standards to be
followed, etc.
• Consider an example of a constraint that can be included in this section—Oracle
DBMS needs to be used as this would facilitate easy interfacing with other
applications that are already operational in the organisation.

b) External interfaces required:

• Examples of external interfaces are— hardware, software and communication

interfaces, user interfaces, report formats, etc.

Seshadri Rao Gudlavalleru Engineering College AS &A 2024-25 Page 28

 R23 SOFTWARE ENGINEERING II [Link]

• To specify the user interfaces, each interface between the software and the users must
be described.
• The description may include sample screen images, any GUI standards or style
guides that are to be followed, screen layout constraints, standard buttons and
functions (e.g., help) that will appear on every screen, keyboard shortcuts, error
message display standards, and so on.
• One example of a user interface requirement of a software can be that it should be
usable by factory shop floor workers who may not even have a high school degree.
The details of the user interface design such as screen designs, menu structure,
navigation diagram, etc. should be documented in a separate user interface
specification document.

c) Other non-functional requirements:

• This section contains a description of non- functional requirements that are neither
design constraints and nor are external interface requirements.
• An important example is a performance requirement such as the number of
transactions completed per unit time.
• Besides performance requirements, the other non-functional requirements to be
described in this section may include reliability issues, accuracy of results, and
security issues.

3. Goals of implementation

• The ‘goals of implementation’ part of the SRS document offers some general
suggestions regarding the software to be developed.
• The goals of implementation section might document issues such system
functionalities that may be required in the future, easier support for new devices to be
supported in the future, reusability issues, etc.
• These are the items which the developers might keep in their mind during
development so that the developed system may meet some aspects that are not
required immediately.
• It is useful to remember that anything that would be tested by the user and the
acceptance of the system would depend on the outcome of this task, is usually
considered as a requirement to be fulfilled by the system and not a goal and vice
versa.

2.7.5 How to classify the different types of requirements?

• Aspects which can be expressed as transformation of some input data to some output
data (i.e., the functions of the system) should be documented as the functional
requirement.
• Any other requirements whose compliance by the developed system can be verified
by inspecting the system are documented as non- functional requirements.
• Aspects whose compliance by the developed system need not be verified but are
included as suggestions to the developers are documented as goals of the
implementation.

Seshadri Rao Gudlavalleru Engineering College AS &A 2024-25 Page 29

 R23 SOFTWARE ENGINEERING II [Link]

Functional Requirements

• In order to document the functional requirements of a system, it is necessary to first

learn to identify the high-level functions of the systems by reading the informal
documentation of the gathered requirements.
• The high-level functions would be split into smaller sub-requirements
• A high-level function is one using which the user can get some useful piece of work
done.
• Example: ATM transaction during withdrawal of money.
• Each high-level requirement typically involves accepting some data from the user
through a user interface, transforming it to the required response, and then displaying
the system response in proper format.
• A high-level function transforms certain input data to output data.
• The different scenarios are essentially different behaviour exhibited by the system for
the same high-level function.
• Typically, each user input and the corresponding system action may be considered as
a sub-requirement of a high-level requirement.
• Thus, each high-level requirement can consist of several sub-requirements.
• The rectangles and circles alternate in the execution of a single high-level function of
the system, indicating a series of requests from the user and the corresponding
responses from the system.
• Typically, there is some initial data input by the user. After accepting this, the system
may display some response (called system action )

Figure: User and system interactions in high-level functional requirement.

Seshadri Rao Gudlavalleru Engineering College AS &A 2024-25 Page 30

 R23 SOFTWARE ENGINEERING II [Link]

How to Identify the Functional Requirements?

• The high-level functional requirements often need to be identified either from an

informal problem description document or from a conceptual understanding of the
problem.
• First identify the different types of users who might use the system and then try to
identify the different services expected from the software by different types of users.
• The decision regarding which functionality of the system can be taken to be a high-
level functional requirement and the one that can be considered as part of another
function (that is, a subfunction) leaves scope for some subjectivity.
• For example, consider the issue-book function in a Library Automation System.
Suppose, when a user invokes the issue-book function, the system would require the
user to enter the details of each book to be issued. Should the entry of the book details
be considered as a high-level function, or as only a part of the issue-book function?
Many times, the choice is obvious. But, sometimes it requires making non-trivial
decisions.

2.7.6 How to Document the Functional Requirements?

• Once all the high-level functional requirements have been identified and the
requirements problems have been eliminated, these are documented.
• A function can be documented by identifying the state at which the data is to be input
to the system, its input data domain, the output data domain, and the type of
processing to be carried on the input data to obtain the output data.
• Let us first try to document the withdraw-cash function of an automated teller
machine (ATM) system in the following. The withdraw-cash is a high-level
requirement. It has several sub-requirements corresponding to the different user
interactions. These user interaction sequences may vary from one invocation from
another depending on some conditions. These different interaction sequences capture
the different scenarios. To accurately describe a functional requirement, we must
document all the different scenarios that may occur.

Example (Withdraw cash from ATM): An initial informal description of a required

functionality is usually given by the customer as a statement of purpose (SoP). An SoP serves
as a starting point for the analyst and he proceeds with the requirements gathering activity
after a basic understanding of the SoP. However, the functionalities of withdraw cash from
ATM is intuitively obvious to anyone who has used a bank ATM. So, we are not including an
informal description of withdraw cash functionality here and in the following, we documents
this functional requirement.

R.1: Withdraw cash

Description: The withdraw cash function first determines the type of account that the user
has and the account number from which the user wishes to withdraw cash. It checks the
balance to determine whether the requested amount is available in the account. If enough
balance is available, it outputs the required cash; otherwise it generates an error message.

R.1.1: Select withdraw amount option

Input: “Withdraw amount” option selected Output: User prompted to enter the account type

Seshadri Rao Gudlavalleru Engineering College AS &A 2024-25 Page 31

 R23 SOFTWARE ENGINEERING II [Link]

R.1.2: Select account type

Input : User selects option from any one of the followings— savings/checking/deposit.

Output: Prompt to enter amount

R.1.3: Get required amount

Input: Amount to be withdrawn in integer values greater than 100 and less than 10,000 in
multiples of 100.

Output: The requested cash and printed transaction statement.

Processing: The amount is debited from the user’s account if sufficient balance is available,
otherwise an error message displayed.

2.7.7 Organisation of the SRS Document

• IEEE 830 standard SRS document has been intended to serve as a guideline for
organizing a requirements specification document into sections and allows the
flexibility of tailoring it, as may be required for specific projects.
• Depending on the type of project being handled, some sections can be omitted,
introduced, or interchanged by the analyst.

Introduction

Purpose: This section should describe where the software would be deployed and and how
the software would be used.

Project scope: This section should briefly describe the overall context within which the
software is being developed. For example, the parts of a problem that are being automated
and the parts that would need to be automated during future evolution of the software.

Environmental characteristics: This section should briefly outline the environment

(hardware and other software) with which the software will interact.

Overall description of organisation of SRS document

Product perspective: This section needs to briefly state as to whether the software is
intended to be a replacement for a certain existing systems, or it is a new software. If the
software being developed would be used as a component of a larger system, a simple
schematic diagram can be given to show the major components of the overall system,
subsystem interconnections, and external interfaces can be helpful.

Product features: This section should summarize the major ways in which the software
would be used. Details should be provided in Section 3 of the document. So, only a brief
summary should be presented here.

Seshadri Rao Gudlavalleru Engineering College AS &A 2024-25 Page 32

 R23 SOFTWARE ENGINEERING II [Link]

User classes: Various user classes that are expected to use this software are identified and
described here. The different classes of users are identified by the types of functionalities that
they are expected to invoke, or their levels of expertise in using computers.

Operating environment: This section should discuss in some detail the hardware platform
on which the software would run, the operating system, and other application software with
which the developed software would interact.

Design and implementation constraints: In this section, the different constraints on the
design and implementation are discussed. These might include—corporate or regulatory
policies; hardware limitations (timing requirements, memory requirements); interfaces to
other applications; specific technologies, tools, and databases to be used; specific
programming language to be used; specific communication protocols to be used; security
considerations; design conventions or programming standards.

User documentation: This section should list out the types of user documentation, such as
user manuals, on-line help, and trouble-shooting manuals that will be delivered to the
customer along with the software.

Assignment-Cum-Tutorial Questions
Part-A
Objective Questions (1M)
(1) Effort is measured using which one of the following units: [ ]
(i) persons
(ii) person-months
(iii) months
(iv) Rupees
(2) COCOMO estimation model can be used to estimate which one of the following: [ ]
(i) LOC
(ii) Effort
(iii) Function points
(iv) Defect density
(3) What is the correct order in which a software project manager estimates various project
parameters while using COCOMO? [ ]
(i) Cost, effort, duration, size
(ii) Cost, duration, effort, size
(iii) Size, effort, duration, cost
(iv) Size, cost, effort, duration

(4) Which one of the following is NOT a factor for “Lines of code” being considered as a
poor size metric? [ ]
(i) It is programming language dependent.
(ii) It penalises efficient and compact coding.

Seshadri Rao Gudlavalleru Engineering College AS &A 2024-25 Page 33

 R23 SOFTWARE ENGINEERING II [Link]

(iii) It is programmer dependent.

(iv) It is dependent on the complexity of the requirements.
(5) Which one of the following project parameters is usually the first to be estimated by a
project manager? [ ]
(i) Cost
(ii) Effort
(iii) Size
(iv) Duration
(6) Which one of the following charts is the most useful to decompose the project activities
into smaller tasks that can be more meaningfully managed: [ ]
(i) PERT chart
(ii) GANTT chart
(iii) Task network representation
(iv) Work breakdown structure
(7) Which one of the following is an example of a multivariable cost estimation model?
(i) Basic COCOMO [ ]
(ii) Intermediate COCOMO
(iii) Complete COCOMO
(iv) Delphi technique
(8) If a software product of size S takes m months to develop, then according to the
COCOMO estimation model, how long (in months) will it take to develop a product of
size 2 × S? [ ]
(i) Greater than 2 × m months
(ii) Greater than 3 × m months
(iii) Less than 2 × m months
(iv) Greater than 4 × m months
(9) Which of the following statements is true of the COCOMO model? [ ]
(i) Cost is the most fundamental attribute of a software product, based on which the
project size and duration are measured.
(ii) Size is the most fundamental attribute of a software product, based on which the
project cost and duration are measured.
(iii) Effort is the most fundamental attribute of a software product, based on which
the project size and cost are measured.

Seshadri Rao Gudlavalleru Engineering College AS &A 2024-25 Page 34

 R23 SOFTWARE ENGINEERING II [Link]

(iv) Duration is the most fundamental attribute of a software product, based on which
the project size and effort are measured.
(10) For a certain software development project, an effort estimation of 100 person- months
was arrived by using COCOMO model. This implies that the project needs to be
completed by: [ ]
(i) Employing 100 persons for 1 month
(ii) Employing 1 person for 100 months
(iii)Employing 10 persons for 10 months
(iv)The number of persons employed over different project phases would correspond
to Raleigh distribution
(11) Who among the following is a stakeholder in a software development project? [ ]
(i) A shareholder of the organisation developing the software
(ii) Anyone who is interested in the software
(iii) Anyone who is a source of requirements for the software
(iv) Anyone who might be affected by the software
(12) A software requirements specification (SRS) document should avoid discussing which
one of the following? [ ]
(i) Functional requirements
(ii) Non-functional requirements
(iii) Design specification
(iv) Constraints on the implementation
(13) Which of the following is not a goal of requirements analysis? [ ]
(i) Weed out ambiguities in the requirements
(ii) Weed out inconsistencies in the requirements
(iii) Weed out non-functional requirements
(iv) Weed out incompleteness in the requirements
(14) Consider the following requirement for word processor software: “The software should
provide facility to import an existing image available as a jpeg file into the document
being created.” Which one of the following types of requirement is this? [ ]
(i) Functional requirement
(ii) Non-functional requirement
(iii) Constraint on the implementation
(iv) Goal of implementation

Seshadri Rao Gudlavalleru Engineering College AS &A 2024-25 Page 35

 R23 SOFTWARE ENGINEERING II [Link]

(15) Assume that you are the project manager of a development project for a data processing
application in which the user requirements for the GUI part are not very clear. Which
life cycle model would you use to develop the GUI part? [ ]
(i) Classical waterfall model
(ii) Iterative waterfall model
(iii) Prototyping model
(iv) Spiral model
Part-B
Short Answer Questions (2M)
1 List five major responsibilities of a software project manager.
2 What is meant by the ‘size’ of a software project?
3 Why does a project manager need to estimate the size of the project?
How is the size estimated?
4 What are the different categories of software development projects
according to the COCOMO estimation model?
5 What do you mean by project size? What are the popular metrics to
measure project size?
6 What is a milestone in software development? Why is it considered
helpful to have milestones in software development?
7 List the important shortcomings of LOC for use as a software size
metric for carrying out project estimations.
8 What is the difference between requirements analysis and specification?
9 What is the difference between the functional and the non-functional
requirements of a system?
10 List five desirable characteristics of a good software requirements
specification (SRS) document.
11 Why is the SRS document also known as the black-box specification of
a system?

Part-C
Descriptive Questions (5M)
1 Suppose you are the project manager of a large development project.
The top management informs that you would have to do with a fixed
BL4
team size (i.e., constant number of developers) throughout the duration
your project. What will be the impact of this decision on your project?
2 Suppose you are developing a software product of organic type. You
have estimated the size of the product to be about 100,000 lines of BL3
code. Compute the nominal effort and the development time.

Seshadri Rao Gudlavalleru Engineering College AS &A 2024-25 Page 36

 R23 SOFTWARE ENGINEERING II [Link]

3 Summarize the relative advantages of using either the LOC or the

function point metric to measure the size of a software product for BL2
software project planning?
4 Outline the important types of risks that a project might suffer from?
How would you identify the risks that a project is susceptible to during BL2
project the project planning stage?
5 What are the important activities carried out during requirements
analysis and specification phase? What is the final outcome of the BL2
requirements analysis and specification phase?
6 List the goals of the requirements analysis and specification
phase? How are the requirements analysis and specification activities BL2
carried out and by whom?
7 Illustrate the important ways in which a well formulated SRS document
BL2
can be useful to various stakeholders.
8 Identify at least two functional requirements
of a bank automated teller machine (ATM) system. Also identify one BL3
non-functional requirement for an ATM system.
9 What are the four types of non-functional requirements that have been
suggested by IEEE 830 standard document. Give one example of each of BL2
these categories of requirements.
10 What do you understand by requirements gathering? Name and explain
the different requirements gathering techniques that are normally BL2
deployed by an analyst.
11 What are the different types of requirements problems that an analyst
usually anticipates and rectifies in the gathered requirements before BL2
starting to write the SRS document? Give at least one example of each.
12 Suppose you have been appointed as the analyst for a large software
development project. Discuss the aspects of the software product you
would document in the software requirements specification (SRS) BL4
document? What would be the organisation of your SRS document? How
would you validate your SRS document?
13
Distinguish functional and non-functional requirements?
BL4
Give one example of each type of requirement for library automation software.

14 Suppose you are trying to gather the requirements for software that needs
to be developed to automate the book-keeping activities of a supermarket.
BL5
Evaluate the main tasks that you would undertake as the analyst to
satisfactorily gather the requirements.
15 Explain different categories of users of the SRS document?
BL2
In what ways is the SRS document useful to them?

Seshadri Rao Gudlavalleru Engineering College AS &A 2024-25 Page 37

 R23 SOFTWARE ENGINEERING II [Link]

16
Illustrate the organisation of the SRS Document BL2

17 Suppose a project was estimated to be 400 KLOC. Calculate the effort and
development time for each of the three model i.e., organic, semi-detached & BL3
embedded.
18 A project size of 200 KLOC is to be developed. Software development team
has average experience on similar type of projects. The project schedule is not
BL3
very tight. Calculate the Effort, development time, average staff size, and
productivity of the project.
19
Distinguish Function points and LOC BL2

Part-D
Competitive Examination Questions
1. Which of the following is not a Non-functional requirement? [NET Dec 2022] [ ]
a) Portability
b) Security
c) Scalability
d) User interaction.
2. Software project manager is responsible for the following task [NET Dec 2022] [ ]
a) Project planning
b) Project status tracking
c) Resources management
d) Risk management
e) Project delivery within time & budget
Choose the correct answer from the options given below.
i)All statements are correct.
ii) Only B & C are correct
iii) Only A & D are correct
iv) Only A & D are correct
3. If every requirement can be checked by a cost-effective process, then SRS is called
[NET June 2022] [ ]
i)Verifiable.
ii) Traceable
iii) Modifiable
iv) Complete
4. Size and complexity are a part of [NET June 2022] [ ]
a) People Metrics
b) Project Metrics
c) Process Metrics

Seshadri Rao Gudlavalleru Engineering College AS &A 2024-25 Page 38

 R23 SOFTWARE ENGINEERING II [Link]

d) Product Metrics.
5. A Software project was estimated at 864 Function Points. A six person team will be
assigned to a project consisting of a requirement gathering person, one designer, two
programmers and two testers. The salary of the designer is Rs.70,000 per month,
requirement gatherer is Rs.50,000 per month, programmer is Rs.60,000 per month and a
tester is Rs.60,000 per month. Average productivity for the team is 12 FP per person
month. Which of the following represents the projected cost of the project?
[NTA UGC NET Nov 2020] [ ]
i) 33,20,000
ii) 43,20,000.
iii) 33,10,000
iv) 22,10,000

Seshadri Rao Gudlavalleru Engineering College AS &A 2024-25 Page 39