Software Engineering 2022-23

By: Nitish Kumar Mohanty

1) a) Differentiate between system engineering and software engineering.

b) What are the drawbacks of spiral model?

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

c) Differentiate between “Known risk” and “predictable risk”.

d) What is cyclomatic complexity?

The cyclomatic complexity of a code section is the quantitative measure of the number of
linearly independent paths in it. It is a software metric used to indicate the complexity of a
program. It is computed using the control flow graph of the program. The nodes in the graph
indicate the smallest group of commands of a program, and a directed edge in it connects the
two nodes i.e. if the second command might immediately follow the first command.

e) List the advantages and disadvantages of using LOC as a metric.

Advantages of Lines of Code (LOC)
• Effort Estimation: LOC is occasionally used to estimate development efforts and project deadlines at a
high level. Although caution is necessary, project planning can begin with this.
• Comparative Analysis: High-level productivity comparisons between several projects or development
teams can be made using LOC. It might provide an approximate figure of the volume of code generated
over a specific time frame.
 • Benchmarking Tool: When comparing various iterations of the same program, LOC can be used as a
benchmarking tool. It may bring information on how modifications affect the codebase’s total size.
Disadvantages of Lines of Code (LOC)
• Challenges in Agile Work Environments: Focusing on initial LOC estimates may not adequately reflect
the iterative and dynamic nature of development in agile development, as requirements may change.
• Not Considering into Account External Libraries: Code from other libraries or frameworks, which can
greatly enhance a project’s overall usefulness, is not taken into account by LOC.
• Challenges with Maintenance: Higher LOC codebases are larger codebases that typically demand more
maintenance work.
•
f) What is meant by Boundary value analysis?

Boundary Value Analysis is based on testing the boundary values of valid and invalid partitions.
The behavior at the edge of the equivalence partition is more likely to be incorrect than the
behavior within the partition, so boundaries are an area where testing is likely to yield defects.

Functional testing verifies that each function of the software application works in conformance
with the requirement and specification. Boundary Value Analysis (BVA) is one of the functional
testings.

g) What is Regression Testing?

Regression testing is like a software quality checkup after any changes are made. It involves
running tests to make sure that everything still works as it should, even after updates or
tweaks to the code. This ensures that the software remains reliable and functions properly,
maintaining its integrity throughout its development lifecycle.

h) What are the common approaches in debugging?

Debugging Approaches
1. Brute Force Method
This is the foremost common technique of debugging however is that the least economical method. during this
approach, the program is loaded with print statements to print the intermediate values with the hope that a
number of the written values can facilitate to spot the statement in error. This approach becomes a lot of
systematic with the utilization of a symbolic program (also known as a source code debugger), as a result of
values of various variables will be simply checked and breakpoints and watch-points can be easily set to check
the values of variables effortlessly.
2. Backtracking
This is additionally a reasonably common approach. during this approach, starting from the statement at which
an error symptom has been discovered, the source code is derived backward till the error is discovered. sadly,
because the variety of supply lines to be derived back will increase, the quantity of potential backward
methods will increase and should become unimaginably large so limiting the utilization of this approach.
3. Cause Elimination Method
In this approach, a listing of causes that may presumably have contributed to the error symptom is developed
and tests are conducted to eliminate every error. A connected technique of identification of the error from the
error symptom is that the package fault tree analysis.
4. Program Slicing
This technique is analogous to backtracking. Here the search house is reduced by process slices. A slice of a
program for a specific variable at a particular statement is that the set of supply lines preceding this statement
which will influence the worth of that variable.

i) Differentiate hard real time & soft real time systems.

j) What are the characteristics of SRS?
characteristics of a good SRS document:

1. Correctness:
User review is used to ensure the correctness of requirements stated in the SRS. SRS is said to be
correct if it covers all the requirements that are actually expected from the system.

2. Completeness:
Completeness of SRS indicates every sense of completion including the numbering of all the pages,
resolving the to be determined parts to as much extent as possible as well as covering all the functional
and non-functional requirements properly.

3. Consistency:
Requirements in SRS are said to be consistent if there are no conflicts between any set of requirements.
Examples of conflict include differences in terminologies used at separate places, logical conflicts like
time period of report generation, etc.

4. Unambiguousness:
A SRS is said to be unambiguous if all the requirements stated have only 1 interpretation. Some of the
ways to prevent unambiguousness include the use of modelling techniques like ER diagrams, proper
reviews and buddy checks, etc.

5. Ranking for importance and stability:

There should a criterion to classify the requirements as less or more important or more specifically as
desirable or essential. An identifier mark can be used with every requirement to indicate its rank or
stability.

6. Modifiability:
SRS should be made as modifiable as possible and should be capable of easily accepting changes to the
system to some extent. Modifications should be properly indexed and cross-referenced.

7. Verifiability:
An SRS is verifiable if there exists a specific technique to quantifiably measure the extent to which every
requirement is met by the system. For example, a requirement starting that the system must be user-
friendly is not verifiable and listing such requirements should be avoided.

8. Traceability:
One should be able to trace a requirement to design component and then to code segment in the
program. Similarly, one should be able to trace a requirement to the corresponding test cases.

9. Design Independence:
There should be an option to choose from multiple design alternatives for the final system. More
specifically, the SRS should not include any implementation details.
 Part-2
2) a) List and describe good characteristics of a good software.
Software engineering is the process of designing, developing, and maintaining software
systems. Good software meets the needs of its users, performs its intended functions reliably,
and is easy to maintain.
1. There are several characteristics of good software that are commonly recognized by
software engineers, which are important to consider when developing a software
system.
2. These characteristics include functionality, usability, reliability, performance, security,
maintainability, reusability, scalability, and testability.
Characteristics of Good Software
1. Functionality: The software meets the requirements and specifications that it was
designed for, and it behaves as expected when it is used in its intended environment.
2. Usability: The software is easy to use and understand, and it provides a positive user
experience.
3. Reliability: The software is free of defects and it performs consistently and accurately
under different conditions and scenarios.
4. Performance: The software runs efficiently and quickly, and it can handle large amounts
of data or traffic.
5. Security: The software is protected against unauthorized access and it keeps the data
and functions safe from malicious attacks.
6. Maintainability: The software is easy to change and update, and it is well-documented,
so that it can be understood and modified by other developers.
7. Reusability: The software can be reused in other projects or applications, and it is
designed in a way that promotes code reuse.

b) Describe how to prepare a software requirement specification (SRS) document. List

possible users and use of SRS for each user.

Steps to Prepare an SRS Document

1. Define the Purpose of the Document: Clearly state the purpose of the SRS and its intended audience.
Mention the product's goals and objectives.
2. Describe the System Scope: Outline what the system will and won’t cover. This gives context for what
will be developed and helps prevent scope creep.
3. Define Functional Requirements: Describe the system’s functional requirements, such as features and
use cases. Each requirement should include:
o Title/Name: Short name for quick reference.
o Description: What the feature or functionality does.
o Inputs and Outputs: Define what the system should receive and output.
 o Dependencies: Other features that interact or rely on this functionality.
4. Define Non-Functional Requirements: Include constraints on system performance, usability, reliability,
security, scalability, etc.
5. List System Interfaces: Specify how the system will interact with hardware, other software, or users.
Describe APIs, protocols, and any third-party software involved.
6. Provide System Diagrams: Use diagrams like flowcharts, ER diagrams, and use-case diagrams to
illustrate the architecture, data flow, and interactions within the system.
7. Include Data Requirements: Define what data will be required, including data storage, data processing,
and data formats.
8. Specify External Requirements: Address any legal, regulatory, or compliance requirements, especially
important in industries like healthcare, finance, and transportation.
9. Add Glossary and Appendices: Include a glossary of terms, acronyms, and abbreviations, as well as any
other relevant information like a list of stakeholders or references.

Possible Users of SRS and How They Use It

1. Project Managers
o Use: For planning, tracking, and managing project scope, timeline, and budget based on the
defined requirements.
2. Developers
o Use: As a guide for implementation, understanding what functionalities to code and the
standards they need to meet.
3. Testers/Quality Assurance Team
o Use: For designing test cases and validating whether the software meets the specified
requirements.
4. Clients/Stakeholders
o Use: To ensure their needs are fully represented in the document and to clarify any ambiguities
about software expectations.
5. Designers (UI/UX)
o Use: To inform design decisions, ensuring user interfaces align with functionality requirements
and user expectations.
6. Maintenance/Support Teams
o Use: For troubleshooting and understanding the functionality and limitations of the system
when issues arise post-deployment.
7. Regulatory and Compliance Officers
o Use: To verify that the software complies with industry regulations and standards before it goes
live.
8. Training Teams
o Use: To develop training materials and ensure users understand the software’s functions and
features.
c) Illustrate functional and nonfunctional requirements in Software Engineering

d) Discuss Object Oriented Analysis (OOA) and modeling in detail.

1. Object-Oriented Analysis (OOA)
Object-Oriented Analysis is the process of examining a problem domain to identify the objects (or entities) that
make up the system and their interactions. OOA focuses on "what" the system should do, helping bridge the
gap between user needs and software functionality. The key goals of OOA are to create a conceptual model of
the system, define its functional requirements, and organize information in a structured way.
Key Concepts in OOA
• Objects: These are instances of classes, representing entities in the system with unique identities and a
set of attributes and behaviors (methods). For example, a Customer or Product in an e-commerce
application.
 • Classes: Templates for objects, encapsulating the data (attributes) and behaviors (methods) that
objects will have. For example, a Customer class might include attributes like name and address and
methods like placeOrder().
• Attributes and Methods:
o Attributes represent the properties or data fields of a class (e.g., name, age).
o Methods are functions that define behaviors or actions associated with a class (e.g., withdraw()
method in an Account class).
• Relationships: Connections between objects or classes. Common relationships include:
o Association: A general connection, often a "has-a" relationship (e.g., an Order "has-a"
Customer).
o Inheritance: An "is-a" relationship, where one class (subclass) inherits properties and behaviors
from another class (superclass). For instance, a SavingsAccount is a type of Account.
o Aggregation: A "whole-part" relationship where one object contains other objects (e.g., a
Library contains Books).
o Composition: A strong form of aggregation where the parts cannot exist independently of the
whole (e.g., Chapters in a Book).
• Encapsulation: Bundling data and methods together within a class and restricting access to some
components to ensure data integrity.
Steps in Object-Oriented Analysis
1. Identify Requirements: Gather and understand user requirements and expectations.
2. Define System Boundaries: Specify what the system includes and excludes, helping to focus on relevant
objects.
3. Identify Key Objects: Recognize real-world entities that relate to the problem domain, such as
Customer, Order, or Product.
4. Define Classes and Relationships: Organize objects into classes, establishing the relationships among
them.
5. Create Object Diagrams: Develop models to visualize how objects interact and relate within the
system.
2. Object-Oriented Modeling (OOM)
Object-Oriented Modeling is the technique of using diagrams to represent the object-oriented design of a
system. It visualizes the system's structure and behavior, aiding in analysis, design, and communication among
development teams. OOM is typically broken into three models: class models, state models, and interaction
models.
Types of OOM Diagrams
1. Class Diagram:
o Represents the static structure of the system, showing classes, their attributes, methods, and
relationships.
o Helps in visualizing the structure and in understanding dependencies and hierarchies.
2. Object Diagram:
o A snapshot of instances of classes at a particular moment, showing the relationship between
objects.
o Useful for clarifying system states or scenarios at specific moments.
 3. Use Case Diagram:
o Shows system functionalities from the user's perspective.
o Defines actors (users or systems interacting with the software) and use cases (system functions),
illustrating "what" the system does.
4. Sequence Diagram:
o Depicts object interactions in a time sequence, focusing on the sequence of messages
exchanged between objects.
o Useful for understanding specific scenarios and workflows in the system.
5. Activity Diagram:
o Visualizes the workflow of activities and actions, similar to a flowchart.
o Helpful for detailing the logic and flow within a use case or a process.
6. State Diagram:
o Models the states an object can be in and how it transitions from one state to another based on
events.
o Useful for systems where an object’s state is critical, like in real-time applications or complex
state-driven processes.
7. Component and Deployment Diagrams:
o Component Diagram: Shows the organization and dependencies of code components (e.g.,
modules, libraries).
o Deployment Diagram: Maps out the physical deployment of software on hardware, illustrating
where components run within a networked environment.

e) Write elaborately on Unit testing and Regression testing. How do you develop test suites?
Unit testing is the process of testing the smallest parts of your code, like individual functions or methods, to
make sure they work correctly. It’s a key part of software development that improves code quality by testing
each unit in isolation.
You write unit tests for these code units and run them automatically every time you make changes. If a test
fails, it helps you quickly find and fix the issue. Unit testing promotes modular code, ensures better test
coverage, and saves time by allowing developers to focus more on coding than manual testing.

To create effective unit tests, follow these basic techniques to ensure all scenarios are covered:
• Logic checks: Verify if the system performs correct calculations and follows the expected path with valid
inputs. Check all possible paths through the code are tested.
• Boundary checks: Test how the system handles typical, edge case, and invalid inputs. For example, if an
integer between 3 and 7 is expected, check how the system reacts to a 5 (normal), a 3 (edge case), and
a 9 (invalid input).
• Error handling: Check the system properly handles errors. Does it prompt for a new input, or does it
crash when something goes wrong?
• Object-oriented checks: If the code modifies objects, confirm that the object’s state is correctly
updated after running the code.
Unit Testing Techniques
There are 3 types of Unit Testing Techniques. They are follows
1. Black Box Testing: This testing technique is used in covering the unit tests for input, user interface, and
output parts.
2. White Box Testing: This technique is used in testing the functional behavior of the system by giving the
input and checking the functionality output including the internal design structure and code of the
modules.
3. Gray Box Testing: This technique is used in executing the relevant test cases, test methods, and test
functions, and analyzing the code performance for the modules.

Regression testing is a crucial aspect of software engineering that ensures the stability and reliability of a
software product. It involves retesting the previously tested functionalities to verify that recent code changes
haven’t adversely affected the existing features.
By identifying and fixing any regression or unintended bugs, regression testing helps maintain the overall
quality of the software. This process is essential for software development teams to deliver consistent and
high-quality products to their users.
Regression testing is like a software quality checkup after any changes are made. It involves running tests to
make sure that everything still works as it should, even after updates or tweaks to the code. This ensures that
the software remains reliable and functions properly, maintaining its integrity throughout its development
lifecycle.

Process of Regression testing

Firstly, whenever we make some changes to the source code for any reason like adding new functionality,
optimization, etc. then our program when executed fails in the previously designed test suite for obvious
reasons. After the failure, the source code is debugged to identify the bugs in the program. After identification
of the bugs in the source code, appropriate modifications are made. Then appropriate test cases are selected
from the already existing test suite which covers all the modified and affected parts of the source code. We can
add new test cases if required. In the end, regression testing is performed using the selected test cases.

Developing Test Suites

A test suite is a collection of test cases organized to test various aspects of a system. Test suites can include
unit tests, integration tests, regression tests, and more. Here’s a step-by-step guide to developing effective test
suites:
1. Define the Scope and Objectives: Clearly outline what the test suite aims to validate. For example:
o Unit Test Suite: Verify the smallest components individually.
o Regression Test Suite: Ensure that existing functionality remains stable after changes.
o Integration Test Suite: Test the interactions between different components.
2. Analyze Requirements and Identify Test Scenarios: Review the requirements or specifications to
identify all relevant scenarios. Focus on common, edge, and negative cases.
o Example for a login feature: Test cases could include successful login, invalid password,
nonexistent user, empty input, etc.
 3. Design Test Cases: Write detailed test cases for each scenario, specifying the following:
o Preconditions: Any setup needed before executing the test.
o Test Steps: Detailed, step-by-step instructions for performing the test.
o Expected Result: The expected outcome if the software is working correctly.
o Post-conditions: Any cleanup required after the test.
4. Automate Test Cases (if applicable): Use tools and frameworks like JUnit, PyTest, or Selenium to
automate the test cases for easier execution and repeatability. For example, unit tests can be
automated with unit test in Python, while Selenium can be used for automating regression tests in web
applications.
5. Organize the Test Cases: Group the test cases logically within the suite, making it easy to identify and
execute specific tests. Common categories include functional tests, security tests, performance tests,
and compatibility tests.
6. Run and Review: Execute the test suite to validate the code. Evaluate results, identify defects, and
document issues. Adjust the suite as needed based on feedback or new test scenarios.
7. Maintain and Update the Test Suite: Regularly update test cases to reflect changes in the code or
requirements. Regression suites, in particular, need constant updates to stay relevant.

f) What is UML? Explain the following in context to UML.

A) Use Case Diagram
B) Sequence Diagram
C) State Diagram
D) Classes and Objects

Unified Modeling Language (UML) is a standardized modeling language used primarily in software engineering
to visualize, specify, construct, and document the structure and behavior of complex systems. UML provides a
variety of diagrams that help represent different aspects of a system, making it easier for developers and
stakeholders to understand and communicate requirements, processes, and workflows.
Here’s a breakdown of each requested component:
A) Use Case Diagram
• Purpose: Represents the functional requirements of a system from the end-user perspective.
• Components:
o Actors: Entities (like users or other systems) that interact with the system.
o Use Cases: Specific functions or services provided by the system to fulfill a goal for the actor.
o Relationships: These can include associations, dependencies, and generalizations between use
cases and actors.
• Use: Use case diagrams are useful for capturing what the system should do without detailing how it
achieves it, making them great for requirements gathering and stakeholder discussions.
B) Sequence Diagram
• Purpose: Illustrates how objects interact in a particular sequence to carry out a specific task or process.
• Components:
o Actors/Objects: Represent entities involved in the interaction.
o Lifelines: Show the lifespan of objects during interactions.
 o Messages: Arrows that indicate communication between objects, often labeled to show the
type of message or operation.
o Activation Bars: Show the period when an object is active or performing a task.
• Use: Sequence diagrams are often used to model the flow of logic within a particular scenario,
showcasing interactions over time, which helps in understanding the sequence of operations.
C) State Diagram
• Purpose: Depicts the different states of an object and transitions based on events.
• Components:
o States: Represent different stages of an object’s life cycle.
o Transitions: Arrows that show how an object moves from one state to another based on events
or conditions.
o Events: Conditions that trigger transitions between states.
• Use: State diagrams are useful for modeling the dynamic behavior of individual objects, especially in
complex systems where objects can undergo numerous state changes, like lifecycle management.
D) Classes and Objects (in UML Context)
• Class:
o Represents a blueprint for objects.
o Contains attributes (properties) and methods (functions) to define what an object of that class
will hold and perform.
• Object:
o An instance of a class that holds actual data and performs defined behaviors.
• Class Diagram:
o Illustrates the relationships and hierarchy between classes and objects.
o Can show inheritance, associations, and dependencies among classes.

g) Explain why it is important to model the context of a system that is being developed. Give
two examples of possible errors that could arise if software engineers do not understand the
system context.

Modeling the context of a system being developed is crucial because it helps software engineers understand
how the system interacts with external entities, users, and other systems. This understanding guides the
design, functionality, and limitations of the software, ensuring it meets user requirements and integrates
seamlessly with other components. By defining the system boundaries, engineers can also identify
dependencies, constraints, and assumptions that might impact the software's success.
If engineers do not model the system context, several errors can arise:
1. Misaligned Functional Requirements: Without a clear understanding of the system's context,
engineers may design features that don’t align with the actual user needs or business objectives. For
example, in a hospital management system, if engineers don’t understand that the system must
interact with patient monitoring devices, they may fail to include necessary interfaces for device
integration, resulting in a system that cannot perform critical functions.
2. Integration Failures: A system often needs to interact with other systems, such as databases, external
APIs, or legacy systems. If the context isn’t understood, engineers may overlook required compatibility
or data-sharing protocols, leading to integration failures. For example, in an e-commerce platform,
 neglecting the context of external payment gateway integration could lead to unsuccessful
transactions, impacting the business's operations and customer satisfaction.
Understanding the system context prevents these errors by ensuring the design and functionality of
the software are aligned with its intended environment and interactions.

h) What is SDLC? Explain the MIS oriented SDLC model.

SDLC is a process followed for software building within a software organization. SDLC consists
of a precise plan that describes how to develop, maintain, replace, and enhance specific
software. The life cycle defines a method for improving the quality of software and the all-
around development process.

SDLC specifies the task(s) to be performed at various stages by a software engineer or

developer. It ensures that the end product is able to meet the customer’s expectations and fits
within the overall budget. Hence, it’s vital for a software developer to have prior knowledge of
this software development process. SDLC is a collection of these six stages, and the stages of
SDLC are as follows:

Stage-1: Planning and Requirement Analysis

Planning is a crucial step in everything, just as in software development. In this same
stage, requirement analysis is also performed by the developers of the organization. This is
attained from customer inputs, and sales department/market surveys.
The information from this analysis forms the building blocks of a basic project. The quality of
the project is a result of planning. Thus, in this stage, the basic project is designed with all the
available information.

Stage-2: Defining Requirements

In this stage, all the requirements for the target software are specified. These requirements get
approval from customers, market analysts, and stakeholders.
This is fulfilled by utilizing SRS (Software Requirement Specification). This is a sort of document
that specifies all those things that need to be defined and created during the entire project
cycle.

Stage-3: Designing Architecture

SRS is a reference for software designers to come up with the best architecture for the
software. Hence, with the requirements defined in SRS, multiple designs for the product
architecture are present in the Design Document Specification (DDS).
This DDS is assessed by market analysts and stakeholders. After evaluating all the possible
factors, the most practical and logical design is chosen for development.
Stage-4: Developing Product
At this stage, the fundamental development of the product starts. For this, developers use a
specific programming code as per the design in the DDS. Hence, it is important for the coders
to follow the protocols set by the association. Conventional programming tools like compilers,
interpreters, debuggers, etc. are also put into use at this stage. Some popular languages like
C/C++, Python, Java, etc. are put into use as per the software regulations.

Stage-5: Product Testing and Integration

After the development of the product, testing of the software is necessary to ensure its
smooth execution. Although, minimal testing is conducted at every stage of SDLC. Therefore, at
this stage, all the probable flaws are tracked, fixed, and retested. This ensures that the product
confronts the quality requirements of SRS.
Documentation, Training, and Support: Software documentation is an essential part of the
software development life cycle. A well-written document acts as a tool and means to
information repository necessary to know about software processes, functions, and
maintenance. Documentation also provides information about how to use the product.
Training in an attempt to improve the current or future employee performance by increasing
an employee’s ability to work through learning, usually by changing his attitude and developing
his skills and understanding.

Stage-6: Deployment and Maintenance of Products

After detailed testing, the conclusive product is released in phases as per the organization’s
strategy. Then it is tested in a real industrial environment. It is important to ensure its smooth
performance. If it performs well, the organization sends out the product as a whole. After
retrieving beneficial feedback, the company releases it as it is or with auxiliary improvements
to make it further helpful for the customers. However, this alone is not enough. Therefore,
along with the deployment, the product’s supervision.

The Management Information Systems (MIS) oriented Software Development Life Cycle
(SDLC) model is an approach to developing systems that focuses on creating information
systems specifically designed to help management in making well-informed, strategic
decisions. The model adapts the traditional SDLC phases to emphasize the collection,
processing, and dissemination of management information, aligning the system's development
process with organizational goals and decision-making needs.
 • Management-Centric: Designed with management and decision-makers in mind,
focusing on information flow and usability.
• Data Integrity and Relevance: Emphasizes ensuring the accuracy, reliability, and
relevance of information that managers use.
• Continuous Alignment with Business Goals: Regular feedback loops to make sure the
MIS evolves with organizational changes and supports strategic planning.

i) Consider a large-scale project for which the manpower requirement is K= 600PY and the
development time is 3 years 6 months. What is the manpower cost after 1 year and 2
months? Calculate the peak time.

j) Explain COCOMO estimation model in software project management.

The COCOMO Model is a procedural cost estimate model for software projects and is often used as a process
of reliably predicting the various parameters associated with making a project such as size, effort, cost, time,
and quality. It was proposed by Barry Boehm in 1981 and is based on the study of 63 projects, which makes it
one of the best-documented models.
The key parameters that define the quality of any software product, which are also an outcome of COCOMO,
are primarily effort and schedule:
1. Effort: Amount of labor that will be required to complete a task. It is measured in person-months units.
2. Schedule: This simply means the amount of time required for the completion of the job, which is, of
course, proportional to the effort put in. It is measured in the units of time such as weeks, and months.
Types of Projects in the COCOMO Model
In the COCOMO model, software projects are categorized into three types based on their complexity, size, and
the development environment. These types are:
1. Organic: A software project is said to be an organic type if the team size required is adequately small,
the problem is well understood and has been solved in the past and also the team members have a
nominal experience regarding the problem.
2. Semi-detached: A software project is said to be a Semi-detached type if the vital characteristics such as
team size, experience, and knowledge of the various programming environments lie in between organic
and embedded. The projects classified as Semi-Detached are comparatively less familiar and difficult to
develop compared to the organic ones and require more experience better guidance and creativity. Eg:
Compilers or different Embedded Systems can be considered Semi-Detached types.
3. Embedded: A software project requiring the highest level of complexity, creativity, and experience
requirement falls under this category. Such software requires a larger team size than the other two
models and also the developers need to be sufficiently experienced and creative to develop such
complex models.
The Six phases of detailed COCOMO are:
Phases of COCOMO Model
1. Planning and requirements: This initial phase involves defining the scope, objectives,
and constraints of the project. It includes developing a project plan that outlines the
schedule, resources, and milestones
2. System design: : In this phase, the high-level architecture of the software system is
created. This includes defining the system’s overall structure, including major
components, their interactions, and the data flow between them.
3. Detailed design: This phase involves creating detailed specifications for each component
of the system. It breaks down the system design into detailed descriptions of each
module, including data structures, algorithms, and interfaces.
4. Module code and test: This involves writing the actual source code for each module or
component as defined in the detailed design. It includes coding the functionalities,
implementing algorithms, and developing interfaces.
5. Integration and test: This phase involves combining individual modules into a complete
system and ensuring that they work together as intended.
6. Cost Constructive model: The Constructive Cost Model (COCOMO) is a widely used
method for estimating the cost and effort required for software development projects.
Different models of COCOMO have been proposed to predict the cost estimation at different
levels, based on the amount of accuracy and correctness required. All of these models can be
applied to a variety of projects, whose characteristics determine the value of the constant to
be used in subsequent calculations. These characteristics of different system types are
mentioned below. Boehm’s definition of organic, semidetached, and embedded systems:
Importance of the COCOMO Model
1. Cost Estimation: To help with resource planning and project budgeting, COCOMO offers
a methodical approach to software development cost estimation.
2. Resource Management: By taking team experience, project size, and complexity into
account, the model helps with efficient resource allocation.
3. Project Planning: COCOMO assists in developing practical project plans that include
attainable objectives, due dates, and benchmarks.
4. Risk management: Early in the development process, COCOMO assists in identifying and
mitigating potential hazards by including risk elements.
5. Support for Decisions: During project planning, the model provides a quantitative
foundation for choices about scope, priorities, and resource allocation.
6. Benchmarking: To compare and assess various software development projects to
industry standards, COCOMO offers a benchmark.
7. Resource Optimization: The model helps to maximize the use of resources, which raises
productivity and lowers costs.

k) Write short notes on Finite State Machine (FSM).

Finite state machine
o Finite state machine is used to recognize patterns.
o Finite automata machine takes the string of symbol as input and changes its state accordingly. In the
input, when a desired symbol is found then the transition occurs.
o While transition, the automata can either move to the next state or stay in the same state.
o FA has two states: accept state or reject state. When the input string is successfully processed and the
automata reached its final state then it will accept.
A finite automata consists of following:
Q: finite set of states
∑: finite set of input symbol
q0: initial state
F: final state
δ: Transition function
Transition function can be defined as
1. δ: Q x ∑ →Q
FA is characterized into two ways:
1. DFA (finite automata)
2. NDFA (non-deterministic finite automata)
DFA
DFA stands for Deterministic Finite Automata. Deterministic refers to the uniqueness of the computation. In
DFA, the input character goes to one state only. DFA doesn't accept the null move that means the DFA cannot
change state without any input character.
DFA has five tuples {Q, ∑, q0, F, δ}
Q: set of all states
∑: finite set of input symbol where δ: Q x ∑ →Q
q0: initial state
F: final state
δ: Transition function
Example
See an example of deterministic finite automata:
1. Q = {q0, q1, q2}
2. ∑ = {0, 1}
3. q0 = {q0}
4. F = {q3}

NDFA
NDFA refer to the Non-Deterministic Finite Automata. It is used to transit the any number of states for a
particular input. NDFA accepts the NULL move that means it can change state without reading the symbols.
NDFA also has five states same as DFA. But NDFA has different transition function.
Transition function of NDFA can be defined as:
δ: Q x ∑ →2Q
Example
See an example of non-deterministic finite automata:
1. Q = {q0, q1, q2}
2. ∑ = {0, 1}
3. q0 = {q0}
4. F = {q3}

l) What are the risk management activities? Is it possible to prioritize the risks? Explain with
suitable example.

Risk management activities are a structured approach to identifying, assessing, and mitigating
potential risks that could impact a project. These activities help teams to proactively address
uncertainties and reduce the likelihood or impact of negative outcomes. Here’s an outline of
the primary risk management activities:

Key Risk Management Activities

1. Risk Identification: Recognizing potential risks that might affect the project’s scope,
timeline, or resources. This involves brainstorming, interviewing stakeholders, and using
historical data from similar projects.
2. Risk Analysis and Assessment: Analyzing the likelihood and potential impact of each
identified risk. Risks are often categorized by their probability of occurrence and their
impact severity, which helps determine how they should be handled.
3. Risk Prioritization: Ranking risks based on their analysis to focus on the most critical
risks first. This helps allocate resources efficiently and ensures high-priority risks receive
attention.
 4. Risk Mitigation and Planning: Developing strategies to manage or reduce
high-priority risks. This can include avoiding the risk, transferring it, reducing
its impact, or accepting it with contingency plans in place.
5. Risk Monitoring and Review: Continuously monitoring identified risks and regularly
reviewing risk plans. New risks may emerge as the project progresses, and identified
risks may evolve, requiring updated strategies.
6. Risk Communication: Keeping all stakeholders informed about identified risks,
mitigation plans, and any changes in risk status throughout the project’s lifecycle.
Prioritizing Risks
Yes, it is possible—and essential—to prioritize risks, as it enables the team to focus on the
most severe or probable risks that could impact project success. Risk prioritization is typically
done by evaluating each risk’s likelihood (probability of occurrence) and its impact on project
objectives (such as cost, timeline, or quality).
Example of Risk Prioritization
Consider a software development project with the following identified risks:
1. Risk A: Uncertain client requirements, which may lead to significant rework.
o Probability: High
o Impact: High
o Priority Level: 1 (Critical risk)
2. Risk B: Lack of skilled developers for a specific technology needed in the project.
o Probability: Medium
o Impact: High
o Priority Level: 2 (High priority)
3. Risk C: Possible delays in hardware procurement.
o Probability: Low
o Impact: Medium
o Priority Level: 3 (Moderate priority)
4. Risk D: Minor changes in project requirements due to regulatory updates.
o Probability: Medium
o Impact: Low
o Priority Level: 4 (Low priority)
In this example:
• Risk A is given the highest priority because it has both a high probability of occurring
and a high impact, meaning it could significantly disrupt the project.
• Risk B is the next priority since it has a high impact but only a medium probability.
• Risk C and Risk D are considered lower priorities due to their lower impacts and
probabilities.
 PART-3
Q3 What is waterfall model for software development? Explain the situation in which the spiral model for
software development should be preferred over waterfall model. A program to be developed to simulate
the operations of a scientific calculator. List the facilities to be provided by this calculator. Analyze this using
a DFD 0-level and 1-level diagram.

Waterfall Model for Software Development

The Waterfall Model is a linear and sequential approach to software development, consisting
of distinct phases where each phase must be completed before the next begins. It’s best suited
for projects with well-defined requirements and minimal expected changes. The phases
typically include:
1. Requirement Gathering and Analysis: Defining and documenting all the requirements.
2. System Design: Planning the architecture and design based on requirements.
3. Implementation: Coding based on the design specifications.
4. Integration and Testing: Testing for functionality and integration issues.
5. Deployment: Deploying the system to the end-user environment.
6. Maintenance: Handling post-deployment issues and updates.
Due to its rigid structure, the Waterfall model is best suited for projects with stable
requirements, where changes during development are minimal, such as in manufacturing or
civil engineering.
When to Prefer the Spiral Model Over the Waterfall Model
The Spiral Model is an iterative, risk-driven model that combines elements of both the
Waterfall and Prototyping models. It focuses on risk assessment and refinement through
multiple cycles, making it suitable for large, complex projects with uncertain requirements.
Situations to Prefer Spiral Over Waterfall:
1. High-Risk Projects: If the project involves complex technologies, high innovation, or
other significant risks, the Spiral Model’s focus on risk analysis makes it more suitable.
2. Uncertain or Evolving Requirements: If requirements are expected to change frequently
or are not clearly defined, the Spiral Model allows for repeated assessment and updates
to the project goals.
3. Client Feedback Requirements: For projects where continuous feedback from the client
is essential, the Spiral Model’s iterative nature supports multiple refinements based on
feedback.
Example Scenario: Scientific Calculator Program
Let’s consider a scientific calculator program. This calculator is expected to provide basic and
advanced mathematical functions for scientific calculations.
Facilities to be Provided by the Scientific Calculator
1. Basic Operations: Addition, subtraction, multiplication, and division.
 2. Scientific Functions: Trigonometric functions (sin, cos, tan), logarithmic functions (log,
ln), exponential functions.
3. Advanced Operations: Square root, power functions, factorial.
4. Memory Functions: Store and retrieve values.
5. Error Handling: Input validation, handling of invalid operations (e.g., division by zero).
Data Flow Diagrams (DFD) for the Scientific Calculator
Level 0 DFD (Context Diagram)
The Level 0 DFD represents the system as a single process and shows the main input and
output interactions.
• User Input: Inputs such as numbers, operation selections, and function commands.
• Calculator System: The main system process that interprets the input, performs
calculations, and returns results.
• Output: Calculation results or error messages displayed to the user.

Level 1 DFD
The Level 1 DFD breaks down the main process into specific functions.
1. Input Validation: Checks user input for errors (e.g., correct format, no division by zero).
2. Basic Operations: Handles addition, subtraction, multiplication, and division.
3. Scientific Functions: Handles trigonometric, logarithmic, and exponential functions.
4. Advanced Operations: Calculates square roots, powers, and factorials.
5. Memory Management: Stores and retrieves values in memory for reuse.
Here’s the structure:
In the Level 1 DFD:
• The Input Validation process first ensures that inputs are valid.
• Basic Operations handles standard arithmetic functions.
• Scientific Functions and Advanced Operations cover more complex calculations.
• Memory Management manages temporary data storage and retrieval.

Q4 Define cohesion and coupling. Explain various types of each of them. What are CASE tools? With a
suitable diagram, explain the categories of CASE tools.

Coupling refers to the degree of interdependence between software modules. High coupling means
that modules are closely connected and changes in one module may affect other modules. Low
coupling means that modules are independent, and changes in one module have little impact on other
modules.

Cohesion refers to the degree to which elements within a module work together to fulfill a single,
well-defined purpose. High cohesion means that elements are closely related and focused on a single
purpose, while low cohesion means that elements are loosely related and serve multiple purposes.
Both coupling and cohesion are important factors in determining the maintainability,
scalability, and reliability of a software system. High coupling and low cohesion can make a
system difficult to change and test, while low coupling and high cohesion make a system easier
to maintain and improve.
Basically, design is a two-part iterative process. The first part is Conceptual Design which tells
the customer what the system will do. Second is Technical Design which allows the system
builders to understand the actual hardware and software needed to solve a customer’s
problem.

The essential idea of CASE tools is that in-built programs can help to analyze developing
systems in order to enhance quality and provide better outcomes. Throughout the 1990, CASE
tool became part of the software lexicon, and big companies like IBM were using these kinds of
tools to help create software.
Various tools are incorporated in CASE and are called CASE tools, which are used to support
different stages and milestones in a software development life cycle.

Types of CASE Tools:

1. Diagramming Tools: It helps in diagrammatic and graphical representations of the data
and system processes. It represents system elements, control flow and data flow among
different software components and system structures in a pictorial form. For example,
Flow Chart Maker tool for making state-of-the-art flowcharts.
2. Computer Display and Report Generators: These help in understanding the data
requirements and the relationships involved.
3. Analysis Tools: It focuses on inconsistent, incorrect specifications involved in the
diagram and data flow. It helps in collecting requirements, automatically check for any
irregularity, imprecision in the diagrams, data redundancies, or erroneous omissions.
For example:
 • (i) Accept 360, Accompa, CaseComplete for requirement analysis.
• (ii) Visible Analyst for total analysis.

4. Central Repository: It provides a single point of storage for data diagrams, reports, and
documents related to project management.
5. Documentation Generators: It helps in generating user and technical documentation as
per standards. It creates documents for technical users and end users.
For example, Doxygen, DrExplain, Adobe RoboHelp for documentation.
6. Code Generators: It aids in the auto-generation of code, including definitions, with the
help of designs, documents, and diagrams.
7. Tools for Requirement Management: It makes gathering, evaluating, and managing
software needs easier.
8. Tools for Analysis and Design: It offers instruments for modelling system architecture
and behavior, which helps throughout the analysis and design stages of software
development.
9. Tools for Database Management: It facilitates database construction, design, and
administration.
10.Tools for Documentation: It makes the process of creating, organizing, and maintaining
project documentation easier.
Q5 Explain Software Reverse Engineering and Software Reengineering. Briefly describe
Service Oriented Architecture (SOA) in software engineering.

Software Reverse Engineering

Reverse engineering can extract design information from source code, but the abstraction
level, the completeness of the documentation, the degree to which tools and a human analyst
work together, and the directionality of the process are highly variable.

Reverse engineering of data occurs at different levels of abstraction .It is often the first
reengineering task.
1. At the program level, internal program data structures must often be reverse
engineered as part of an overall reengineering effort.
2. At the system level, global data structures (e.g., files, databases) are often reengineered
to accommodate new database management paradigms (e.g., the move from flat file to
relational or object-oriented database systems).
Internal Data Structures
Reverse engineering techniques for internal program data focus on the definition of classes of
objects.
1. This is accomplished by examining the program code with the intent of grouping related
program variables.
2. In many cases, the data organization within the code identifies abstract data types.
3. For example, record structures, files, lists, and other data structures often provide an
initial indicator of classes.
Database Structures
A database allows the definition of data objects and supports some method for establishing
relationships among the objects. Therefore, reengineering one database schema into another
requires an understanding of existing objects and their relationships.
The following steps define the existing data model as a precursor to reengineering a new
database model:
1. Build an initial object model.
2. Determine candidate keys (the attributes are examined to determine whether they are
used to point to another record or table; those that serve as pointers become candidate
keys).
3. Refine the tentative classes.
4. Define generalizations.
Software Re-Engineering
Software Re-Engineering is the examination and alteration of a system to reconstitute it in a
new form. The principle of Re-Engineering when applied to the software development process
is called software re-engineering. It positively affects software cost, quality, customer service,
and delivery speed. In Software Re-engineering, we are improving the software to make it
more efficient and effective.
It is a process where the software’s design is changed and the source code is created from
scratch. Sometimes software engineers notice that certain software product components need
more upkeep than other components, necessitating their re-engineering.
The re-Engineering procedure requires the following steps
1. Decide which components of the software we want to re-engineer. Is it the complete
software or just some components of the software?
2. Do Reverse Engineering to learn about existing software functionalities.
3. Perform restructuring of source code if needed for example modifying functional-
Oriented programs in Object-Oriented programs
4. Perform restructuring of data if required
5. Use Forward Engineering ideas to generate re-engineered software

The need for software Re-engineering: Software re-engineering is an economical process for
software development and quality enhancement of the product. This process enables us to
identify the useless consumption of deployed resources and the constraints that are restricting
the development process so that the development process could be made easier and cost-
effective (time, financial, direct advantage, optimize the code, indirect benefits, etc.) and
maintainable.

Service-Oriented Architecture (SOA) is a stage in the evolution of application development

and/or integration. It defines a way to make software components reusable using the
interfaces.
Formally, SOA is an architectural approach in which applications make use of services available
in the network. In this architecture, services are provided to form applications, through a
network call over the internet. It uses common communication standards to speed up and
streamline the service integrations in applications. Each service in SOA is a complete business
function in itself. The services are published in such a way that it makes it easy for the
developers to assemble their apps using those services. Note that SOA is different from
microservice architecture.
• SOA allows users to combine a large number of facilities from existing services to form
applications.
 • SOA encompasses a set of design principles that structure system development and
provide means for integrating components into a coherent and decentralized system.
• SOA-based computing packages functionalities into a set of interoperable services,
which can be integrated into different software systems belonging to separate business
domains.
The different characteristics of SOA are as follows:
o Provides interoperability between the services.
o Provides methods for service encapsulation, service discovery, service composition,
service reusability and service integration.
o Facilitates QoS (Quality of Services) through service contract based on Service Level
Agreement (SLA).
o Provides loosely couples services.
o Provides location transparency with better scalability and availability.
o Ease of maintenance with reduced cost of application development and
deployment.
There are two major roles within Service-oriented Architecture:
1. Service provider: The service provider is the maintainer of the service and the
organization that makes available one or more services for others to use. To advertise
services, the provider can publish them in a registry, together with a service contract
that specifies the nature of the service, how to use it, the requirements for the service,
and the fees charged.
2. Service consumer: The service consumer can locate the service metadata in the registry
and develop the required client components to bind and use the service.

Services might aggregate information and data retrieved from other services or create
workflows of services to satisfy the request of a given service consumer. This practice is known
as service orchestration Another important interaction pattern is service choreography, which
is the coordinated interaction of services without a single point of control.
Components of SOA:

Q6 What are the different architectural styles applied for software development? Explain
with diagrams. What is acceptance testing? Explain briefly alpha testing and beta testing
with suitable examples.

1. Monolithic Architecture:
One of the earliest and most basic architectural forms is monolithic architecture. The system is
intended to function as a single, self-contained unit in a monolithic application. Each
component, including the data access layer, business logic, and user interface, is closely
integrated into a single codebase.
Characteristics:
o Tight Coupling: When parts are closely connected, it is challenging to scale or modify
individual elements without influencing the system as a whole.
o Simplicity: Small to medium-sized applications might benefit from monolithic
architectures since they are easy to build and implement.
o Performance: Monolithic programs can be quite performant because there are no inter-
process communication overheads.
Use Cases:
Monolithic designs work well in smaller applications where performance and ease of use are
more important than scalability and flexibility. Some e-commerce websites, blogging platforms,
and content management systems (CMS) are a few examples.
2. Layered Architecture:
Layered architecture, sometimes called n-tier architecture, divides the software system into
several levels, each in charge of a certain task. Better system organization and maintainability
are made possible by this division.
Characteristics:
o Separation of Concerns: Distinct concerns, like data access, business logic, and display,
are handled by different levels.
o Scalability: The ability to scale individual layers allows for improved resource and
performance usage.
o Reusability: Reusing components from one layer in other applications or even in other
sections of the system is frequently possible.
Use Cases:
Web applications, enterprise software, and numerous client-server systems are just a few
applications that use layered structures. They offer an excellent mix of maintainability,
scalability, and modifiability.

3. Architecture of Client-Server:
The system is divided into two primary parts by client-server architecture: the client, which is
responsible for the user interface, and the server, which is in charge of data management and
business logic. A network is used to facilitate communication between the client and server.
Characteristics:
o Scalability: This design works well for large-scale applications since servers may be
scaled independently to accommodate growing loads.
o Centralized Data Management: Since data is kept on the server, security and
management can be done centrally.
o Thin Clients: Since most work occurs on the server, clients can be quite light.
Use Cases:
Web applications, email services, and online gaming platforms are just a few of the networked
applications that rely on client-server architectures.
4. Microservices Foundation:
A more modern architectural style called microservices architecture encourages the creation of
autonomous, little services that speak to one another via APIs. Every microservice
concentrates on a certain business function.
Characteristics:
o Decomposition: The system is broken down into smaller, more manageable services to
improve flexibility and adaptability.
o Independent Deployment: Continuous delivery is made possible by microservices'
ability to be deployed and upgraded separately.
o Scalability: Individual services can be scaled to maximize resource utilization.
Use Cases:
Large and complicated apps like social media networks, cloud-native apps, and e-commerce
platforms are frequently built using microservices. They work effectively when fault tolerance,
scalability, and quick development are crucial.
5. Event-Driven Architecture:
The foundation of event-driven architecture is the asynchronous event-driven communication
between components. An event sets off particular responses or actions inside the system.
Characteristics:
o Asynchronous Communication: Independently published, subscribed to, and processed
events allow for component-to-component communication.
o Loose coupling: Because of their loose coupling, event-driven systems have more
flexibility regarding component interactions.
o Scalability: Event-driven systems scale effectively and can withstand heavy loads.
Use Cases:
Financial systems, Internet of Things platforms, and online multiplayer games are a few
examples of applications where event-driven architectures are appropriate since they require
real-time processing, flexibility, and scalability.

6. Service-Oriented Architecture:
A type of architecture known as service-oriented architecture, or SOA, emphasizes providing
services as the fundamental units of larger systems. Services may be coordinated to build large
systems since they are meant to be autonomous, reusable, and flexible.
Characteristics:
o Reusability: To minimize effort duplication, services are made to be used again in many
situations.
o Interoperability: SOA strongly emphasizes using open standards to ensure that services
from various suppliers can cooperate.
o Flexibility: Adaptability is made possible by orchestrating services to develop various
applications.
Use Cases:
Enterprise-level applications that necessitate integrating several systems and services
frequently employ SOA. It also frequently occurs in systems when various teams or
organizations have developed separate application components.
7. Peer-to-Peer Architecture:
Peer-to-peer (P2P) architecture enables communication and resource sharing between
networked devices or nodes without depending on a centralized server. Every network node
can serve as both a client and a server.
Characteristics:
o Decentralization: The lack of a single point of failure in P2P systems results from their
decentralization.
o Resource Sharing: Nodes can share resources such as files, processing power, and
network bandwidth.
o Autonomy: Every node inside the network possesses a certain level of autonomy,
enabling it to make decisions on its own.
Use Cases:
Peer-to-peer (P2P) architectures are widely employed in distributed systems, video
conferencing software, and file-sharing programs. In these applications, nodes cooperate and
exchange resources without a central authority.

8. Architecture in N-Tiers:
An expansion of layered architecture, which divides the system into several tiers or layers, each
with a distinct function, is known as N-tier architecture. Presentation, application, business
logic, and data storage layers are examples of these tiers.
Characteristics:
o Modularity: N-Tier designs divide intricate systems into more manageable, smaller
parts.
o Scalability: Performance can be optimized by scaling each layer independently.
o Security: Data security can be improved by physically or logically separating data storage
levels.
Use Cases:
N-tier architectures are frequently employed in web applications where a distinct division of
responsibilities is necessary. They work great in scenarios where maintainability, scalability, and
modifiability are crucial.

9. Cloud-Based Architecture:
Software systems are developed and delivered using cloud-based architecture, which uses
cloud computing services. Outsourcing infrastructure to cloud service providers makes
scalability, adaptability, and cost-effectiveness possible.
Characteristics:
o Scalability: Cloud services are easily expandable or contracted to accommodate
fluctuating needs.
o Cost-effectiveness: Cloud-based architecture lowers initial hardware purchase
requirements and ongoing maintenance expenses.
o Worldwide Accessibility: Cloud architecture enables applications to be accessed from
anywhere in the world.
Use Cases:
Enterprise systems, mobile apps, and online applications are among the use cases for cloud-
based architectures. They are helpful when programs must manage changing workloads or
when regional distribution is crucial.

x-X-x