Unit 1

Components of Software :
There are three components of the software: These are : Program, Documentation, and Operating
Procedures.
 Program –
A computer program is a list of instructions that tell a computer what to do.
 Documentation –
Source information about the product contained in design documents, detailed code
comments, etc.
 Operating Procedures –
Set of step-by-step instructions compiled by an organization to help workers carry out
complex routine operations.
 Code: the instructions that a computer executes in order to perform a specific task or set of
tasks.
 Data: the information that the software uses or manipulates.
 User interface: the means by which the user interacts with the software, such as buttons,
menus, and text fields.
 Libraries: pre-written code that can be reused by the software to perform common tasks.
 Documentation: information that explains how to use and maintain the software, such as
user manuals and technical guides.
 Test cases: a set of inputs, execution conditions, and expected outputs that are used to test
the software for correctness and reliability.
 Configuration files: files that contain settings and parameters that are used to configure the
software to run in a specific environment.
 Build and deployment scripts: scripts or tools that are used to build, package, and deploy the
software to different environments.
 Metadata: information about the software, such as version numbers, authors, and copyright
information.
Characteristics of software include:
Software engineering is the process of designing, developing, testing, and maintaining software. The
characteristics of software include:
1. It is intangible, meaning it cannot be seen or touched.
2. It is non-perishable, meaning it does not degrade over time.
3. It is easy to replicate, meaning it can be copied and distributed easily.
4. It can be complex, meaning it can have many interrelated parts and features.
5. It can be difficult to understand and modify, especially for large and complex systems.
6. It can be affected by changing requirements, meaning it may need to be updated or modified
as the needs of users change.
7. It can be affected by bugs and other issues, meaning it may need to be tested and debugged
to ensure it works as intended.
 Software Crisis(4)
It can be defined as set of problems raised during the software development periods
The causes of software crisis are linked to all the problems and complexities associated with
development process
Causes of Software Crisis:
 Over budget
 Poor project management.
 At that time Software was never delivered
 Difficult to alter, debug, and enhance
 Lack of adequate training in software engineering.
 Less skilled project members.
 Low productivity improvements.
 Solution of Software Crisis:
There is no single solution to the crisis. One possible solution to a software crisis is Software
Engineering because software engineering is a systematic, disciplined, and quantifiable approach. For
preventing software crises, there are some guidelines:
 Reduction in software over budget.
 The quality of software must be high.
 Less time is needed for a software project.
 Experienced and skilled people working over the software project.
 Software must be delivered.
 Software must meet user requirements.

What is Software Engineering?

The term software engineering is the product of two words, software, and engineering. The software
is a collection of integrated programs.
Software subsists of carefully-organized instructions and code written by developers on any of
various particular computer languages.
Engineering is the application of scientific and practical knowledge to invent, design, build, maintain,
and improve frameworks, processes, etc.
Software Engineering is an engineering branch related to the evolution of software product using
well-defined scientific principles, techniques, and procedures. The result of software engineering is
an effective and reliable software product.
Why is Software Engineering required?
o To manage Large software
o For more Scalability
o Cost Management
o To manage the dynamic nature of software
o For better quality Management
o Huge Programming: It is simpler to manufacture a wall than to a house or building, similarly,
as the measure of programming become extensive engineering has to step to give it a
scientific process.
o Adaptability: If the software procedure were not based on scientific and engineering ideas, it
would be simpler to re-create new software than to scale an existing one.
o Cost: As the hardware industry has demonstrated its skills and huge manufacturing has let
down the cost of computer and electronic hardware. But the cost of programming remains
high if the proper process is not adapted.
 o Dynamic Nature: The continually growing and adapting nature of programming hugely
depends upon the environment in which the client works. If the quality of the software is
continually changing, new upgrades need to be done in the existing one.
o Quality Management: Better procedure of software development provides a better and
quality software product.

What is Software development life cycle(SDLC)?

A software life cycle model (also termed process model) is a pictorial and diagrammatic
representation of the software life cycle.
A life cycle model represents all the methods required to make a software product transit through its
life cycle stages. It also captures the structure in which these methods are to be undertaken.
Need of SDLC
Without using an exact life cycle model, the development of a software product would not be in a
systematic and disciplined manner.
When a team is developing a software product, there must be a clear understanding among team
representative about when and what to do. Otherwise, it would point to chaos and project failure.
Steps of SDLC model are as follow:
o Feasibility study
o Requirement analysis
o System specification
o System and component design
o Implementation and component testing
o System testing
o Operation and Maintenance
WATERFALL MODEL
The Waterfall Model was the first Process Model to be introduced. It is also referred to as a linear-
sequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase
must be completed before the next phase can begin and there is no overlapping in the [Link]
Waterfall model is the earliest SDLC approach that was used for software development.
The waterfall Model illustrates the software development process in a linear sequential flow. This
means that any phase in the development process begins only if the previous phase is complete. In
this waterfall model, the phases do not overlap.
Waterfall Model - Design
Waterfall approach was first SDLC Model to be used widely in Software Engineering to ensure
success of the project. In "The Waterfall" approach, the whole process of software development is
divided into separate phases. In this Waterfall model, typically, the outcome of one phase acts as the
input for the next phase sequentially.
The following illustration is a representation of the different phases of the Waterfall Model.
SDLC Waterfall Model
The sequential phases in Waterfall model are −
 Requirement Gathering and analysis − All possible requirements of the system to be
developed are captured in this phase and documented in a requirement specification
document.
 System Design − The requirement specifica ons from first phase are studied in this phase
and the system design is prepared. This system design helps in specifying hardware and
system requirements and helps in defining the overall system architecture.
  Implementation − With inputs from the system design, the system is first developed in small
programs called units, which are integrated in the next phase. Each unit is developed and
tested for its functionality, which is referred to as Unit Testing.
 Integration and Testing − All the units developed in the implementa on phase are integrated
into a system after testing of each unit. Post integration the entire system is tested for any

Advantages Dis-Advantages
Before the next phase of development, each phase Error can be fixed only during the phase
must be completed
Suited for smaller projects where requirements are It is not desirable for complex project where
well defined requirement changes frequently
They should perform quality assurance test Testing period comes quite late in the
(Verification and Validation) before completing each developmental process
stage
Elaborate documentation is done at every phase of Documentation occupies a lot of time of developers
the software’s development cycle and testers
Project is completely dependent on project team Clients valuable feedback cannot be included with
with minimum client intervention ongoing development phase
Any changes in software is made during the process Small changes or errors that arise in the completed
of the development software may cause a lot of problems
faults and failures.
 Deployment of system − Once the func onal and non-functional testing is done; the product
is deployed in the customer environment or released into the market.
 Maintenance − There are some issues which come up in the client environment. To fix those
issues, patches are released. Also to enhance the product some better versions are released.
Maintenance is done to deliver these changes in the customer environment.
Prototype Model
The prototype model requires that before carrying out the development of actual software, a
working prototype of the system should be built. A prototype is a toy implementation of the system.
A prototype usually turns out to be a very crude version of the actual system, possible exhibiting
limited functional capabilities, low reliability, and inefficient performance as compared to actual
software. In many instances, the client only has a general view of what is expected from the software
product. In such a scenario where there is an absence of detailed information regarding the input to
the system, the processing needs, and the output requirement, the prototyping model may be
employed.

Steps of Prototype Model

1. Requirement Gathering and Analyst

2. Quick Decision
3. Build a Prototype
4. Assessment or User Evaluation
5. Prototype Refinement
6. Engineer Product

Advantage of Prototype Model

1. Reduce the risk of incorrect user requirement

2. Good where requirement are changing/uncommitted
3. Regular visible process aids management
 4. Support early product marketing
5. Reduce Maintenance cost.
6. Errors can be detected much earlier as the system is made side by side.

Disadvantage of Prototype Model

1. An unstable/badly implemented prototype often becomes the final product.

2. Require extensive customer collaboration
3. Costs customer money
4. Needs committed customer
5. Difficult to finish if customer withdraw
EVOLUTIONARY LIFECYCLE MODEL -
It is also called Rapid Application Model(RAD) At first, a simple working model is built. Subsequently
it undergoes functional improvements & we keep on adding new functions till the desired system is
built.
Evolutionary Lifecycle Model is shown in below fig.

Versions Are developed in a sequential manner rather than in parallel and within each version
development Cycle, there is a normal progression through analysis, design, code,test and
Implementation, followed operations and maintenance.
Every developed version evolves according to customer’s point of view.

Applications:
 Large projects where you can easily find modules for incremental implementation.
 It is used when the customer wants to start using the core features rather than waiting for
the full software.
  Also used in object oriented software development because the system can be easily
portioned into units in terms of objects.

Advantages:
 User gets a chance to experiment partially developed system
 Reduce the error because the core modules get tested thoroughly
 It reduces risk of software projects.
 It enables faster incremented improvements to exiting products
Disadvantages:
 It is difficult to divide the problem into several versions that would be acceptable to the
customer which can be incrementally implemented & delivered.
 Several versions: Developer has to make table versions which increase their effort
 Difficulty in estimating of costs at the start of project due to customer’s requirements.
 Delivery of project may be late if the requirements are not achieved.
Benefits of Evolutionary Process Model

 Use of EVO brings a significant reduction in risk for software projects.

 Play Video
 EVO can reduce costs by providing a structured, disciplined avenue for experimentation.
 EVO allows the marketing department access to early deliveries, facilitating the development
of documentation and demonstration.
 Better fit the product to user needs and market requirements.
 Manage project risk with the definition of early cycle content.
 Uncover key issues early and focus attention appropriately.
 Increase the opportunity to hit market windows.
 Accelerate sales cycles with early customer exposure.
 Increase management visibility of project progress.

Prototyping Lifecycle Model

Prototyping is based on the idea of developing an initial implementation for user feedback, and then
refining this prototype through many versions until a satisfactory system emerges.
Advantages
 Customers get a say in the product early on, increasing customer satisfaction.
 Missing functionality and errors are detected easily.
 Prototypes can be reused in future, more complicated projects.
 It emphasizes team communication and flexible design practices.
 Users have a better understanding of how the product works.
 Quicker customer feedback provides a better idea of customer needs.
Disadvantages
 The main disadvantage of this methodology is that it is more costly in terms of time and
money when compared to alternative development methods, such as the spiral or Waterfall
model. Since in most cases the prototype is discarded, some companies may not see the
value in taking this approach.
  Additionally, inviting customer feedback so early on in the development lifecycle may cause
problems. One problem is that there may be an excessive amount of change requests that
may be hard to accommodate. Another issue could arise if after seeing the prototype, the
customer demands a quicker final release or becomes uninterested in the product.

Project Scheduling
A schedule in your project’s time table actually consists of sequenced activities and milestones that
are needed to be delivered under a given period of time.

Project schedule simply means a mechanism that is used to communicate and know about that tasks
are needed and has to be done or performed and which organizational resources will be given or
allocated to these tasks and in what time duration or time frame work is needed to be performed.
Effective project scheduling leads to success of project, reduced cost, and increased customer
satisfaction. Scheduling in project management means to list out activities, deliverables, and
milestones within a project that are delivered. It contains more notes than your average weekly
planner notes. The most common and important form of project schedule is Gantt chart.

Process :
The manager needs to estimate time and resources of project while scheduling project. All activities
in project must be arranged in a coherent sequence that means activities should be arranged in a
logical and well-organized manner for easy to understand. Initial estimates of project can be made
optimistically which means estimates can be made when all favorable things will happen and no
threats or problems take place.
The total work is separated or divided into various small activities or tasks during project schedule.
Then, Project manager will decide time required for each activity or task to get completed. Even
some activities are conducted and performed in parallel for efficient performance. The project
manager should be aware of fact that each stage of project is not problem-free.
Problems arise during Project Development Stage :
1. People may leave or remain absent during particular stage of development.
2. Hardware may get failed while performing.
3. Software resource that is required may not be available at present, etc.
4. The project schedule is represented as set of chart in which work-breakdown structure and
dependencies within various activities are represented. To accomplish and complete project
within a given schedule, required resources must be available when they are needed.
Therefore, resource estimation should be done before starting development.
Resources required for Development of Project :
1. Human effort
2. Sufficient disk space on server
3. Specialized hardware
4. Software technology
5. Travel allowance required by project staff, etc.
6. Advantages of Project Scheduling :
There are several advantages provided by project schedule in our project management:
1. It simply ensures that everyone remains on same page as far as tasks get completed,
dependencies, and deadlines.
 2. It helps in identifying issues early and concerns such as lack or unavailability of resources.
3. It also helps to identify relationships and to monitor process.
4. It provides effective budget management and risk mitigation.
Project Planning(4)
Once a project is found to be possible, computer code project managers undertake project designing.
Project designing is undertaken and completed even before any development activity starts. Project
designing consists of subsequent essential activities:
Estimating the subsequent attributes of the project:
 Project size:What’s going to be downside quality in terms of the trouble and time needed to
develop the product?
 Cost:What proportion is it reaching to value to develop the project?
 Duration:However long is it reaching to want complete development?
 Effort:What proportion effort would be required?
The effectiveness of the following designing activities relies on the accuracy of those estimations.
 planning force and alternative resources
 workers organization and staffing plans
 Risk identification, analysis, and abatement designing
 Miscellaneous arranges like quality assurance plan, configuration, management arrange, etc.

Unit 2
Explain Feasibility Study and its types?
Feasibility Study in Software Engineering is a study to evaluate feasibility of proposed project or
system. Feasibility study is one of stage among important four stages of Software Project
Management Process. As name suggests feasibility study is the feasibility analysis or it is a measure
of the software product in terms of how much beneficial product development will be for the
organization in a practical point of view. Feasibility study is carried out based on many purposes to
analyze whether software product will be right in terms of development, implantation, contribution
of project to the organization etc.
Need of Feasibility Study :
Feasibility study is so important stage of Software Project Management Process as after completion
of feasibility study it gives a conclusion of whether to go ahead with proposed project as it is
practically feasible or to stop proposed project here as it is not right/feasible to develop or to
think/analyze about proposed project again.
Along with this Feasibility study helps in identifying risk factors involved in developing and deploying
system and planning for risk analysis also narrows the business alternatives and enhance success rate
analyzing different parameters associated with proposed project development.
Types of Feasibility Study :
The feasibility study mainly concentrates on below five mentioned areas. Among these Economic
Feasibility Study is most important part of the feasibility analysis and Legal Feasibility Study is less
considered feasibility analysis.

1. Technical Feasibility –
In Technical Feasibility current resources both hardware software along with required technology are
analyzed/assessed to develop project. This technical feasibility study gives report whether there
exists correct required resources and technologies which will be used for project development. Along
with this, feasibility study also analyzes technical skills and capabilities of technical team, existing
technology can be used or not, maintenance and up-gradation is easy or not for chosen technology
etc.
2. Operational Feasibility –
In Operational Feasibility degree of providing service to requirements is analyzed along with how
much easy product will be to operate and maintenance after deployment. Along with this other
operational scopes are determining usability of product, Determining suggested solution by software
development team is acceptable or not etc.
3. Economic Feasibility –
In Economic Feasibility study cost and benefit of the project is analyzed. Means under this feasibility
study a detail analysis is carried out what will be cost of the project for development which includes
all required cost for final development like hardware and software resource required, design and
development cost and operational cost and so on. After that it is analyzed whether project will be
beneficial in terms of finance for organization or not.
4. Legal Feasibility –
In Legal Feasibility study project is analyzed in legality point of view. This includes analyzing barriers
of legal implementation of project, data protection acts or social media laws, project certificate,
license, copyright etc. Overall it can be said that Legal Feasibility Study is study to know if proposed
project conform legal and ethical requirements.

5. Schedule Feasibility –
In Schedule Feasibility Study mainly timelines/deadlines is analyzed for proposed project which
includes how many times teams will take to complete final project which has a great impact on the
organization as purpose of project may fail if it can’t be completed on time.
Aim of feasibility study :
the overall objective of the organization are covered and contributed by the system or not.
the implementation of the system be done using current technology or not.
can the system be integrated with the other system which are already exist
Feasibility Study Process :
The below steps are carried out during entire feasibility analysis.
 Information assessment
 Information collection
 Report writing
 General information

What is dfd?
A data flow diagram (DFD) is a graphical representation of the flow of data within a system. It is a
modeling technique used to describe the flow of data, information, and knowledge within a system
or process. A DFD provides a clear and concise view of the flow of data, and can be used to identify
opportunities for improvement and to simplify complex systems.

A DFD consists of four main components:

1. Processes: Represent the activities or transformations that data undergoes as it flows

through the system.
 2. Data stores: Represent the storage locations where data is temporarily or permanently
stored, such as databases or file systems.

3. Data flows: Represent the movement of data from one process or data store to another.

4. External entities: Represent sources or sinks of data that are external to the system, such as
users, other systems, or devices.

DFDs are often used in software development to model the flow of data within software systems, to
identify potential bottlenecks or inefficiencies in the flow of data, and to guide the development of
software systems in a structured and organized manner. They can also be used in business and
organizational contexts, to model the flow of data within an organization and to support process
improvement efforts.

By providing a clear and concise view of the flow of data within a system, DFDs can help
organizations to understand their data and information systems, and to identify opportunities for
improvement and efficiency gains.

Explain SRS?what is the goal of SRS and Characteristics of SRS?

Software document specification
 A set of documents that contains the concise and clear specification of the
functional,performance,design and interface requirements of the propose system.
 A set of precisely stated properties which a software system must satisfy.
Characteristics/Features of an SRS
1. Correct -- should accurately reflect product functionality and specification at any point of
time.
2. Unambiguous -- should not be any confusion regarding interpretation of the requirements.
3. Complete -- should contain all the features requested by a client.
4. Consistent -- same abbreviation and conventions must be followed throughout the
document.
5. Ranked for importance and/or stability -- every requirement is important. But some are
urgent and must be fulfilled before other requirements and some could be delayed. It’s
better to classify each requirement according to its importance and stability.
6. Verifiable -- an SRS is verifiable only if every stated requirement can be verified. A
requirement is verifiable if there is some method to quantifiably measure whether the final
software meets that requirement.
7. Modifiable -- an SRS must clearly identify each and every requirement in a systematic
manner. If there are any changes, the specific requirements and the dependent ones can be
modified accordingly without impact the others.
8. Traceable – an SRS is traceable if the origin of each of its requirements is clear and if it makes
it easy to reference each requirement in future development.
The goals of an SRS
 Provide feedback to the customer, ensuring that the IT company understands the issues the
software system should solve and how to address those issues.
 Help to break a problem down into smaller components just by writing down the
requirements.
 Speed up the testing and validation processes.
 Facilitate reviews.
Define functional and non-functional requirements?
Functional requirements Non-Functional requirements
1. It defines system of component 1. It defines the quality attribute of a software
system
2. It specifies what should the software 2. It places constrains on how should the
system should do software system fulfil Functional
requirements
3. It is specified by user 3.
4. It is captured in use case 4. It is captured in attribute case
5. Define at a component level 5. Applied to a system
6. It helps you to verify functionality of a 6. It helps you to verify the performance of
software the software
7. Testing like integration, end to end, 7. Testing like performance , stress ,usability,
API testing are done security testing are done
8. Usually easy to define 8. More difficult to define

Explain Software metrics and its categories?

 A software metric is a measure of software characteristics which are measurable or
countable.
 Software metrics are valuable for many reasons, including measuring software performance,
planning work items, measuring productivity, and many other uses.
 Within the software development process, many metrics are that are all connected. Software
metrics are similar to the four functions of management: Planning, Organization, Control, or
Improvement.
Categories of Software metrics
1. Product Metrics: Product metrics are used to evaluate the state of the product, tracing risks
and undercover prospective problem areas. The ability of the team to control quality is
evaluated. Characteristics of product-
 Size
 Complexity
 Design
 Features
 Performance
 Efficiency
 reliability
2. Process Metrics: Process metrics pay particular attention to enhancing the long-term process
of the team or [Link] describes the effectiveness and quality of the processes that
produce the software product
Example
 Effort required in the process.
 Time to produce the product
 Maturity of the process
 Effectiveness of defect removal during development
3. Project Metrics: The project matrix describes the project characteristic and execution
process.
 Number of software developer
 Staffing patterns over the life cycle of software
 Cost and schedule
  Productivity

Advantage of Software Metrics

1. Comparative study of various design methodology of software systems.
2. For analysis, comparison, and critical study of different programming language
concerning their characteristics.
3. In comparing and evaluating the capabilities and productivity of people involved in
software development.
4. In the preparation of software quality specifications.
5. In the verification of compliance of software systems requirements and specifications.
6. In making inference about the effort to be put in the design and development of the
software systems.
7. In getting an idea about the complexity of the code.
8. In taking decisions regarding further division of a complex module is to be done or not.
9. In guiding resource manager for their proper utilization.
10. In comparison and making design tradeoffs between software development and
maintenance cost.
Disadvantage of Software Metrics
1. The application of software metrics is not always easy, and in some cases, it is difficult
and costly.
2. The verification and justification of software metrics are based on historical/empirical
data whose validity is difficult to verify.
3. These are useful for managing software products but not for evaluating the performance
of the technical staff.
4. The definition and derivation of Software metrics are usually based on assuming which
are not standardized and may depend upon tools available and working environment.
5. Most of the predictive models rely on estimates of certain variables which are often not
known precisely.
COCOMO MODEL
Boehm proposed COCOMO (Constructive Cost Estimation Model) in [Link] is one of the
most generally used software estimation models in the world. COCOMO predicts the efforts and
schedule of a software product based on the size of the software.
The necessary steps in this model are:
1. Get an initial estimate of the development effort from evaluation of thousands of delivered
lines of source code (KDLOC).
2. Determine a set of 15 multiplying factors from various attributes of the project.
3. Calculate the effort estimate by multiplying the initial estimate with all the multiplying
factors i.e., multiply the values in step1 and step2.
The initial estimate (also called nominal estimate) is determined by an equation of the form used in
the static single variable models, using KDLOC as the measure of the size. To determine the initial
effort Ei in person-months the equation used is of the type is shown below
Ei=a*(KDLOC)b
The value of the constant a and b are depends on the project type.
In COCOMO, projects are categorized into three types:
1. Organic
2. Semidetached
3. Embedded
[Link]: A development project can be treated of the organic type, if the project deals with
developing a well-understood application program, the size of the development team is reasonably
small, and the team members are experienced in developing similar methods of projects. Examples
of this type of projects are simple business systems, simple inventory management systems, and
data processing systems.
2. Semidetached: A development project can be treated with semidetached type if the development
consists of a mixture of experienced and inexperienced staff. Team members may have finite
experience in related systems but may be unfamiliar with some aspects of the order being
developed. Example of Semidetached system includes developing a new operating system (OS), a
Database Management System (DBMS), and complex inventory management system.
3. Embedded: A development project is treated to be of an embedded type, if the software being
developed is strongly coupled to complex hardware, or if the stringent regulations on the operational
method exist. For Example: ATM, Air Traffic control.
For three product categories, Bohem provides a different set of expression to predict effort (in a unit
of person month)and development time from the size of estimation in KLOC(Kilo Line of code) efforts
estimation takes into account the productivity loss due to holidays, weekly off, coffee breaks, etc.
According to Boehm, software cost estimation should be done through three stages:
1. Basic Model
2. Intermediate Model
3. Detailed Model
1. Basic COCOMO Model: The basic COCOMO model provide an accurate size of the project
parameters. The following expressions give the basic COCOMO estimation model:
Effort=a1*(KLOC) a2 PM
Tdev=b1*(efforts)b2 Months
Where
KLOC is the estimated size of the software product indicate in Kilo Lines of Code,
a1,a2,b1,b2 are constants for each group of software products,
Tdev is the estimated time to develop the software, expressed in months,
Effort is the total effort required to develop the software product, expressed in person months
(PMs).
Estimation of development effort
For the three classes of software products, the formulas for estimating the effort based on the code
size are shown below:
Organic: Effort = 2.4(KLOC) 1.05 PM
Semi-detached: Effort = 3.0(KLOC) 1.12 PM
Embedded: Effort = 3.6(KLOC) 1.20 PM
Estimation of development time
For the three classes of software products, the formulas for estimating the development time based
on the effort are given below:
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
Some insight into the basic COCOMO model can be obtained by plotting the estimated
characteristics for different software sizes. Fig shows a plot of estimated effort versus product size.
From fig, we can observe that the effort is somewhat superliner in the size of the software product.
Thus, the effort required to develop a product increases very rapidly with project size.
Intermediate Model: The basic Cocomo model considers that the effort is only a function of the
number of lines of code and some constants calculated according to the various software systems.
The intermediate COCOMO model recognizes these facts and refines the initial estimates obtained
through the basic COCOMO model by using a set of 15 cost drivers based on various attributes of
software engineering.
Classification of Cost Drivers and their attributes:
(i) Product attributes -
o Required software reliability extent
o Size of the application database
o The complexity of the product
Hardware attributes -
o Run-time performance constraints
o Memory constraints
o The volatility of the virtual machine environment
o Required turnabout time
Personnel attributes -
o Analyst capability
o Software engineering capability
o Applications experience
o Virtual machine experience
o Programming language experience
Project attributes -
o Use of software tools
o Application of software engineering methods
o Required development schedule
The cost drivers are divided into four categories:
3. Detailed COCOMO Model:Detailed COCOMO incorporates all qualities of the standard version
with an assessment of the cost driver?s effect on each method of the software engineering process.
The detailed model uses various effort multipliers for each cost driver property. In detailed cocomo,
the whole software is differentiated into multiple modules, and then we apply COCOMO in various
modules to estimate effort and then sum the effort.
The Six phases of detailed COCOMO are:
1. Planning and requirements
2. System structure
3. Complete structure
4. Module code and test
5. Integration and test
6. Cost Constructive model
The effort is determined as a function of program estimate, and a set of cost drivers are given
according to every phase of the software lifecycle.
Empirical Estimation Technique –(4)
Empirical estimation is a technique or model in which empirically derived formulas are used for
predicting the data that are a required and essential part of the software project planning step.
These techniques are usually based on the data that is collected previously from a project and also
based on some guesses, prior experience with the development of similar types of projects, and
assumptions. It uses the size of the software to estimate the effort.
In this technique, an educated guess of project parameters is made. Hence, these models are based
on common sense. However, as there are many activities involved in empirical estimation
techniques, this technique is formalized.
 Unit 3
Explain Modularization?(4)
Modularization
 It is a technique to divide a software system into multiple discrete and independent
modules, which are expected to be capable of carrying out task(s) independently.
 These modules may work as basic constructs for the entire software.
 Designers tend to design modules such that they can be executed and/or compiled
separately and independently.
 Modular design unintentionally follows the rules of ‘divide and conquer’ problem-solving
strategy this is because there are many other benefits attached with the modular design
of a software.
Advantage of modularization:
 Smaller components are easier to maintain
 Program can be divided based on functional aspects
 Desired level of abstraction can be brought in the program
 Components with high cohesion can be re-used again
 Concurrent execution can be made possible
 Desired from security aspect
What is coupling and cohesion in software design?(4)
Cohesion
Cohesion is a measure that defines the degree of intra-dependability within elements of a
module. The greater the cohesion, the better is the program design.
There are seven types of cohesion, namely –
 Co-incidental cohesion - It is unplanned and random cohesion, which might be the result of
breaking the program into smaller modules for the sake of modularization. Because it is
unplanned, it may serve confusion to the programmers and is generally not-accepted.
 Logical cohesion - When logically categorized elements are put together into a module, it is
called logical cohesion.
 Temporal Cohesion - When elements of module are organized such that they are processed
at a similar point in time, it is called temporal cohesion.
 Procedural cohesion - When elements of module are grouped together, which are executed
sequentially in order to perform a task, it is called procedural cohesion.
 Communicational cohesion - When elements of module are grouped together, which are
executed sequentially and work on same data (information), it is called communicational
cohesion.
 Sequential cohesion - When elements of module are grouped because the output of one
element serves as input to another and so on, it is called sequential cohesion.
 Functional cohesion - It is considered to be the highest degree of cohesion, and it is highly
expected. Elements of module in functional cohesion are grouped because they all
contribute to a single well-defined function. It can also be reused.
Coupling
Coupling is a measure that defines the level of inter-dependability among modules of a program.
It tells at what level the modules interfere and interact with each other. The lower the coupling,
the better the program.
There are five levels of coupling, namely -
  Content coupling - When a module can directly access or modify or refer to the content of
another module, it is called content level coupling.
 Common coupling- When multiple modules have read and write access to some global data,
it is called common or global coupling.
 Control coupling- Two modules are called control-coupled if one of them decides the
function of the other module or changes its flow of execution.
 Stamp coupling- When multiple modules share common data structure and work on
different part of it, it is called stamp coupling.
 Data coupling- Data coupling is when two modules interact with each other by means of
passing data (as parameter). If a module passes data structure as parameter, then the
receiving module should use all its components.
Ideally, no coupling is considered to be the best.
Differentiate coupling and cohesion(4)(integrate both for8marks)
Coupling Cohesion
1. Coupling deals with how much one module 1. Cohesion deals with how much the
is dependent on the other program functionality are related to each other
modules. within the module.
2. Coupling shows the relative independence 2. - Cohesion shows the module’s relative
among the modules. functional strength
3. Coupling is the indication of the 3. - Cohesion is the indication of the
relationships between modules. relationship within module.
4. Coupling is a measure of the degree of 4. -Cohesion is the measure of strength of the
independence between modules. association of elements within 3 module.

5. The modules are described as tightly 5. . Cohesion is highest in modules that have a
coupled when there is a high degree of single, clear, logically independent
interaction. responsibility or role.

In software testing, we have four different levels of testing, which are as discussed below:
1) Unit Testing
2) Integration Testing
3) System Testing
4) Acceptance Testing
Define various Level of software testing?(8)
 A level of software testing is a process where every unit or component of a software or
system is tested.
 The main reason for implementing the levels of testing is to make the software
testing process efficient and easy to find all possible test cases at a specific level.
 To check the behaviour or performance of software testing, we have various testing levels.
The above-described software testing levels are developed to identify missing areas and
understanding between the development life cycle conditions.

Level1: Unit Testing

 Unit testing is the first level of software testing, which is used to test if software modules are
satisfying the given requirement or not.
  The first level of testing involves analyzing each unit or an individual component of the
software application.
 The primary purpose of executing unit testing is to validate unit components with their
performance.
 It will help the test engineer and developers in order to understand the base of code that
makes them able to change defect causing code quickly. The developers implement the unit.
Level2: Integration Testing
 The second level of software testing is the integration testing. The integration testing process
comes after unit testing.
 It is mainly used to test the data flow from one module or component to other modules.
 In integration testing, the test engineer tests the units or separate components or modules
of the software in a group.
 The primary purpose of executing the integration testing is to identify the defects at the
interaction between integrated components or units.
 When each component or module works separately, we need to check the data flow
between the dependent modules, and this process is known as integration testing.
 We only go for the integration testing when the functional testing has been completed
successfully on each application module.
 In simple words, we can say that integration testing aims to evaluate the accuracy of
communication among all the modules.
Level3: System Testing
 The third level of software testing is system testing, which is used to test the software's
functional and non-functional requirements.
 It is end-to-end testing where the testing environment is parallel to the production
environment. In the third level of software testing, we will test the application as a whole
system.
 To check the end-to-end flow of an application or the software as a user is known as System
testing.
 In system testing, we will go through all the necessary modules of an application and test if
the end features or the end business works fine, and test the product as a complete system.
 In simple words, we can say that System testing is a sequence of different types of tests to
implement and examine the entire working of an integrated software computer system
against requirements.
Level4: Acceptance Testing
 The last and fourth level of software testing is acceptance testing, which is used to evaluate
whether a specification or the requirements are met as per its delivery.
 The software has passed through three testing levels (Unit Testing, Integration Testing,
System Testing). Some minor errors can still be identified when the end-user uses the system
in the actual scenario.
 In simple words, we can say that Acceptance testing is the squeezing of all the testing
processes that are previously done.
 The acceptance testing is also known as User acceptance testing (UAT) and is done by the
customer before accepting the final product.
 Usually, UAT is done by the domain expert (customer) for their satisfaction and checks
whether the application is working according to given business scenarios and real-time
scenarios.
Concept of Software Design(4)(for 8 marks integrate modularization
coupling and cohesion)
Software Design is the process to transform the user requirements into some suitable form, which
helps the programmer in software coding and implementation. During the software design phase,
the design document is produced, based on the customer requirements as documented in the SRS
document. Hence the aim of this phase is to transform the SRS document into the design document.
Software Design Levels
 Architectural Design - The architectural design is the highest abstract version of the system.
It identifies the software as a system with many components interacting with each other. At
this level, the designers get the idea of proposed solution domain.
 High-level Design- The high-level design breaks the ‘single entity-multiple component’
concept of architectural design into less-abstracted view of sub-systems and modules and
depicts their interaction with each other. High-level design focuses on how the system along
with all of its components can be implemented in forms of modules. It recognizes modular
structure of each sub-system and their relation and interaction among each other.
 Detailed Design- Detailed design deals with the implementation part of what is seen as a
system and its sub-systems in the previous two designs. It is more detailed towards modules
and their implementations. It defines logical structure of each module and their interfaces to
communicate with other modules.
The following items are designed and documented during the design phase:

 Different modules required.

 Control relationships among modules.
 Interface among different modules.
 Data structure among the different modules.
 Algorithms required to implement among the individual modules.
Objectives of Software Design:
1. Correctness:
A good design should be correct i.e. it should correctly implement all the functionalities of
the system.
2. Efficiency:
A good software design should address the resources, time, and cost optimization issues.
3. Understandability:
A good design should be easily understandable, for which it should be modular and all the
modules are arranged in layers.
4. Completeness:
The design should have all the components like data structures, modules, and external
interfaces, etc.
5. Maintainability:
A good software design should be easily amenable to change whenever a change request is
made from the customer side.

Software Design Levels

 Architectural Design - The architectural design is the highest abstract version of the system.
It identifies the software as a system with many components interacting with each other. At
this level, the designers get the idea of proposed solution domain.
 High-level Design- The high-level design breaks the ‘single entity-multiple component’
concept of architectural design into less-abstracted view of sub-systems and modules and
 depicts their interaction with each other. High-level design focuses on how the system along
with all of its components can be implemented in forms of modules. It recognizes modular
structure of each sub-system and their relation and interaction among each other.
 Detailed Design- Detailed design deals with the implementation part of what is seen as a
system and its sub-systems in the previous two designs. It is more detailed towards modules
and their implementations. It defines logical structure of each module and their interfaces to
communicate with other modules.

Software Reliability(4)
 Software Reliability means Operational reliability. It is described as the ability of a system or
component to perform its required functions under static conditions for a specific period.
 Software reliability is also defined as the probability that a software system fulfills its
assigned task in a given environment for a predefined number of input cases, assuming that
the hardware and the input are free of error.
 Software Reliability is an essential connect of software quality, composed with functionality,
usability, performance, serviceability, capability, installability, maintainability, and
documentation. Software Reliability is hard to achieve because the complexity of software
turn to be high. While any system with a high degree of complexity, containing software, will
be hard to reach a certain level of reliability, system developers tend to push complexity into
the software layer, with the speedy growth of system size and ease of doing so by upgrading
the software.
 For example, large next-generation aircraft will have over 1 million source lines of software
on-board; next-generation air traffic control systems will contain between one and two
million lines; the upcoming International Space Station will have over two million lines on-
board and over 10 million lines of ground support software; several significant life-critical
defense systems will have over 5 million source lines of software. While the complexity of
software is inversely associated with software reliability, it is directly related to other vital
factors in software quality, especially functionality, capability, etc.

UNIT 4
Software re-engineering
Software re-engineering is the process of transforming a software system into a new or improved
form. This can involve updating the code to modern programming standards, adding new features,
fixing bugs, improving performance, or making the software more maintainable.

Re-engineering is often necessary when the original software system has become outdated or no
longer meets the needs of the users. It is also used when a company acquires an existing software
system and needs to integrate it into its existing infrastructure.

The process of re-engineering can be complex and time-consuming, as it involves not only updating
the code but also understanding the system's architecture, data structures, and algorithms. It also
requires careful planning and testing to ensure that the re-engineered system continues to meet the
requirements and is compatible with other systems.
Overall, software re-engineering can provide many benefits, including improved software quality,
increased efficiency, and reduced maintenance costs.

Reverse engineering is the process of analyzing a software system to understand how it works, how it
was built, and how it can be improved. It is often used to uncover the design and architecture of a
system, including the data structures and algorithms used, as well as to identify and fix bugs or
security vulnerabilities.

Reverse engineering can be applied to a wide range of software systems, from old, legacy systems to
modern, complex software applications. The process typically involves disassembling the software
into its component parts, examining the code and other artifacts, and creating a comprehensive map
of the system's architecture and functionality.

Reverse engineering can be useful in many different scenarios, such as:

 When a company wants to integrate an existing software system into its existing
infrastructure.

 When a software vendor wants to understand the internal workings of a competitor's

software in order to improve its own product.

 When a software system needs to be updated or re-engineered and the original source code
is no longer available.

 When a company needs to understand the potential security risks posed by a third-party
software system.

Overall, reverse engineering is an important tool for understanding how software systems work and
for improving their functionality, performance, and security. However, it is important to be mindful of
the ethical and legal implications of reverse engineering, as it can sometimes involve the
unauthorized use of proprietary information.

Software Configuration Management (SCM)

IT is the process of tracking and controlling changes to a software system, including its source code,
documentation, and other artifacts. The goal of SCM is to ensure that the software system is reliable,
efficient, and easy to maintain over time.

Some common activities involved in software configuration management include:

1. Version control: Keeping track of changes made to the software system over time and
managing different versions of the code.

2. Build management: Automating the process of building the software system, including
compiling the code, creating executables, and generating documentation.

3. Branching and merging: Creating separate branches of the codebase to work on separate
features or bug fixes, and then merging those changes back into the main codebase.

4. Continuous integration: Automatically building and testing the software system whenever
changes are made to the code, to detect and fix problems early.

5. Release management: Creating and managing releases of the software system, including
preparing and distributing software packages and tracking bugs and issues.
 6. Compliance and auditing: Ensuring that the software system complies with industry
standards and regulations, and maintaining an auditable record of changes to the code.

7. Documentation: Keeping documentation up-to-date, including source code comments, user

manuals, and other technical documents.

By implementing effective software configuration management practices, organizations can improve

the quality and reliability of their software systems, reduce the time and effort required to maintain
the systems, and increase the speed of development.

Software Quality Assurance (SQA)

Software Quality Assurance (SQA) is a process that ensures that a software system meets specified
quality criteria and standards. The goal of SQA is to prevent defects and improve the overall quality
of the software, resulting in a better user experience and increased customer satisfaction.

SQA activities include a wide range of tasks, such as:

1. Requirements analysis: Ensuring that the software requirements are well-defined and
accurately reflect the needs of the users.

2. Design and code review: Conducting reviews of the software design and code to identify
potential problems and ensure that the code is well-written and meets standards.

3. Testing: Conducting a variety of tests, including unit tests, integration tests, system tests, and
user acceptance tests, to verify that the software works as intended and meets quality
criteria.

4. Defect tracking: Tracking and reporting defects in the software, and ensuring that they are
fixed in a timely and effective manner.

5. Configuration management: Managing changes to the software system, including version

control and release management, to ensure that the software remains stable and reliable
over time.

6. Metrics and reporting: Collecting and analyzing data on software quality, including defect
rates, test coverage, and code complexity, to identify areas for improvement.

7. Process improvement: Continuously reviewing and improving the SQA process to ensure that
it remains effective and efficient.

SQA is an ongoing process that involves collaboration among various stakeholders, including
developers, testers, project managers, and customers. By implementing a robust SQA process,
organizations can improve the quality of their software systems, reduce the number of defects, and
increase customer satisfaction.

Software quality attributes

Software quality attributes are characteristics of a software system that affect its ability to meet the
needs of its users and stakeholders. These attributes describe the non-functional aspects of the
software, such as performance, security, reliability, usability, and maintainability.

Some common software quality attributes include:

 1. Performance: The ability of the software system to meet its performance requirements, such
as response time, throughput, and scalability.

2. Security: The ability of the software system to protect sensitive information, such as user
data and confidential business information, from unauthorized access or theft.

3. Reliability: The ability of the software system to operate correctly and consistently over time,
and to recover from errors and failures.

4. Usability: The ease of use and user-friendliness of the software system, including its user
interface, navigation, and help features.

5. Maintainability: The ability of the software system to be updated and modified over time,
and to remain effective and efficient in the face of changing requirements.

6. Testability: The ability of the software system to be tested and validated effectively, including
the ease of creating and executing tests, and the availability of test data and tools.

7. Portability: The ability of the software system to run on different hardware and software
platforms, and to be easily migrated to new environments.

8. Flexibility: The ability of the software system to adapt to changing requirements and
environments, and to be easily modified to meet new needs.

Software quality attributes are important considerations in the software development process, as
they can greatly impact the success and adoption of the software system. By focusing on these
attributes, organizations can improve the overall quality and value of their software systems.

Software reuse
refers to the practice of using existing software components, modules, or systems in the
development of new software applications, instead of writing new code from scratch. The goal of
software reuse is to improve software development efficiency, reduce costs, and increase the
reliability and quality of the software.

There are several benefits to software reuse, including:

1. Increased development efficiency: By reusing existing software components, developers can

reduce the amount of time and effort required to write new code, freeing up time for other
tasks.

2. Improved software quality: Reused software components have been tested and validated,
reducing the risk of defects and increasing the reliability of the new software application.

3. Reduced costs: By reusing existing software components, organizations can reduce the cost
of software development and maintenance, as well as the cost of acquiring new software.

4. Improved maintainability: Reused software components are easier to maintain and update
than custom-written code, as they are well-documented and have been tested and validated.
 5. Increased compatibility: Reused software components are often compatible with other
systems and software, reducing the risk of compatibility issues and making it easier to
integrate the new software with existing systems.

There are several strategies for promoting software reuse, including the creation of software libraries
and component repositories, the use of software frameworks and design patterns, and the
development of software standards and guidelines. By adopting a culture of software reuse,
organizations can improve the quality, efficiency, and cost-effectiveness of their software
development processes.

Software Maintenance
is an important aspect of software development, as it helps to ensure that software systems
continue to meet the needs of their users and stakeholders over time. The need for maintenance
arises from several factors, including:

1. Changes in requirements: Software systems are often developed to meet specific

requirements, but as those requirements change over time, the software may need to be
updated to reflect those changes.

2. Bug fixing: Software systems may contain defects or bugs that need to be fixed to ensure
that they continue to work as intended.

3. Performance optimization: Over time, software systems may become slow or inefficient, and
may need to be optimized to improve their performance.

4. Security updates: Software systems may need to be updated to address security

vulnerabilities or to comply with new security standards and regulations.

5. Operating system updates: As new versions of operating systems are released, software
systems may need to be updated to work correctly on the new platforms.

6. Technology changes: As technology advances, software systems may need to be updated to

take advantage of new features and capabilities.

There are several categories of software maintenance, including:

1. Corrective maintenance: This type of maintenance is focused on fixing bugs and defects in
the software system. The goal of corrective maintenance is to restore the software system to
its correct behavior, and to prevent the same defects from recurring in the future.

2. Adaptive maintenance: This type of maintenance is focused on making changes to the

software system to accommodate changes in its environment or requirements. The goal of
adaptive maintenance is to ensure that the software system continues to meet the needs of
its users and stakeholders, even as those needs change over time.

3. Perfective maintenance: This type of maintenance is focused on improving the functionality,

performance, and quality of the software system. The goal of perfective maintenance is to
enhance the software system's capabilities and to make it more user-friendly and efficient.

4. Preventive maintenance: This type of maintenance is focused on preventing problems from

occurring in the software system. The goal of preventive maintenance is to identify and
 address potential problems before they cause problems, and to ensure that the software
system continues to operate smoothly and efficiently.

5. Infrastructure maintenance: This type of maintenance is focused on maintaining the

underlying hardware and software infrastructure that the software system relies on. The goal
of infrastructure maintenance is to ensure that the software system continues to work
correctly and efficiently, even as the hardware and software platforms evolve over time.

By categorizing maintenance activities into these different types, organizations can prioritize their
maintenance efforts and allocate resources more effectively, ensuring that they maintain the
software system in a way that is both cost-effective and that meets the needs of its users and
stakeholders.

Topics not covered

Function point(unit 1)
Cocomo model(padha nahi dhyan se)