SE DEC 2022

Q1.

a. Explain the CMM model.



b. Explain the Requirement Model

 Requirements for a computer-based system can be seen in many different ways. Some so ware
people argue that it’s worth using a number of different modes of representa on while others
believe that it’s best to select one mode of representa on. The specific

elements of the requirements model

are dedicated to the analysis modelling method that is to be used.

Scenario-based elements: Using a scenario-based approach, system is described from user’s point of
view. For example, basic use cases and their corresponding use-case diagrams evolve into more
elaborate template-based use cases. Figure 1(a) depicts a UML ac vity diagram for elici ng
requirements and represen ng them using use cases. There are three levels of elabora on.

Class-based elements: A collec on of things that have similar a ributes and common behaviours i.e.,
objects are categorized into classes. For example, a UML case diagram can be used to depict a Sensor
class for the Safe Home security func on. Note that diagram lists a ributes of sensors and
opera ons that can be applied to modify these a ributes. In addi on to class diagrams, other
analysis modelling elements depict manner in which classes collaborate with one another and
rela onships and interac ons between classes.
Behavioural elements: Effect of behaviour of computer-based system can be seen on design that is
chosen and implementa on approach that is applied. Modelling elements that depict behaviour
must be provided by requirements model.

For example, in a requirement model for an online booking system, use case diagrams might
illustrate the interac ons between users and the system, depic ng scenarios such as making a
reserva on, cancelling a booking, or viewing available op ons. Flowcharts could detail the sequence
of involved in each use case, providing a clear understanding of the system's func onality.

c. Explain the LOC

 A line of code (LOC) is any line of text in a code that is not a comment or blank line, and also
header lines, in any case of the number of statements or fragments of statements on the line. LOC
clearly consists of all lines containing the declara on of any variable, and executable and non-
executable statements. As Lines of Code (LOC) only counts the volume of code, you can only use it to
compare or es mate projects that use the same language and are coded using the same coding
standards.

Features :

 Varia ons such as “source lines of code”, are used to set out a codebase.
 LOC is frequently used in some kinds of arguments.
 They are used in assessing a project’s performance or efficiency.

Advantages :

 Most used metric in cost es ma on.

 Its alternates have many problems as compared to this metric.
 It is very easy in es ma ng the efforts.

Disadvantages :

 Very difficult to es mate the LOC of the final program from the problem specifica on.
 It correlates poorly with quality and efficiency of code.
 It doesn’t consider complexity.

Research has shown a rough correla on between LOC and the overall cost and length of developing a
project/ product in So ware Development, and between LOC and the number of defects. This means
the lower your LOC measurement is, the be er off you probably are in the development of your
product.
d. What are the design principles


e. Explain the so ware tes ng process.


f. Discuss the different level of DFD.

Q2.

a. Explain Risk and its types. Explain the steps involved in se ng up a RMMM plan.

b. Explain the spiral model of so ware development.

Q3.

a. Explain the general format of SRS.


So ware Requirement Specifica on (SRS) Format as the name suggests, is a complete specifica on
and descrip on of requirements of the so ware that need to be fulfilled for the successful
development of the so ware system. These requirements can be func onal as well as non-func onal
depending upon the type of requirement. The interac on between different customers and
contractors is done because it is necessary to fully understand the needs of customers.

 Introduc on

Purpose of this Document – At first, main aim of why this document is necessary and what’s purpose
of document is explained and described.

Scope of this document – In this, overall working and main objec ve of document and what value it
will provide to customer is described and explained. It also includes a descrip on of development
cost and me required.

Overview – In this, descrip on of product is explained. It’s simply summary or overall review of
product.

 General descrip on

In this, general func ons of product which includes objec ve of user, a user characteris c, features,
benefits, about why its importance is men oned. It also describes features of user community.

 Func onal Requirements

In this, possible outcome of so ware system which includes effects due to opera on of program is
fully explained. All func onal requirements which may include calcula ons, data processing, etc. are
placed in a ranked order.

 Performance Requirements

In this, how a so ware system performs desired func ons under specific condi on is explained. It
also explains required me, required memory, maximum error rate, etc. The performance
requirements part of an SRS specifies the performance constraints on the so ware system.

 Design Constraints

In this, constraints which simply means limita on or restric on are specified and explained for design
team. Examples may include use of a par cular algorithm, hardware and so ware limita ons, etc.

 Non-Func onal A ributes

In this, non-func onal a ributes are explained that are required by so ware system for be er
performance. An example may include Security, Portability, Reliability, Reusability, Applica on
compa bility, Data integrity, Scalability capacity, etc.

 Preliminary Schedule and Budget

In this, ini al version and budget of project plan are explained which include overall me dura on
required and overall cost required for development of project.
  Appendices

In this, addi onal informa on like references from where informa on is gathered, defini ons of
some specific terms, acronyms, abbrevia ons, etc. are given and explained.

 Uses of SRS document

For what purpose are you crea ng this document.

 FAQs on SRS Format

1. Why is it important to define the scope of an SRS document?

2. What are func onal requirements in an SRS document, and why are they important?

 Conclusion

So ware development requires a well-structured So ware Requirement Specifica on (SRS). It helps

stakeholders communicate, provides a roadmap for development teams, guides testers in crea ng
effec ve test plans, guides maintenance and support employees, informs project management
decisions, and sets customer expecta ons.

b. Explain the FP es ma on techniques in detail.


Func on Point Es ma on: Func on Point Es ma on begins with iden fying the func ons in the
so ware. Once the so ware func on to be tested is iden fied, it is distributed among the resources
available, and the me required to test each func on is calculated.

In this es ma on technique, we use weights and hence calculate the es ma on for en re func ons
that are under test by mul plying the (weight * dura on). To do this, we do the following steps:

Iden fy the smallest func on under test and assign the weight as One.

Finding the me required to test the func on.

Iden fy other func ons as well and similarly calculate the me to test the func ons by mul plying
the (weight * dura on).

Once all func ons are es mated, we add them to calculate the total effort required for conduc ng
the tes ng.

This technique introduces us to the concept of func onal point (FP). The FP is assigned for the
modules having varying complexi es – Easy, medium, and hard. The tasks which are simpler as
assigned lesser points and for difficult tasks higher number of points are assigned.

Example: Let us then take the example of the same applica on that we took under considera on for
Three-Point Es ma on. The applica on has various components: Frontend, Backend, database, and
business logic layer. Now, all of the components in the applica on have easy, medium, and difficult
modules. Therefore, segrega ng the project into modules:

Assume FP = $10 per points.

Q4.

a. Explain cohesion and coupling. Explain different types with detailed example.

b. Explain the different techniques in white box tes ng


Q5.

a. Explain steps in version and change control.


b. Explain so ware reverse engineering in detail.

Q6.

a. Compare FTR and Walkthrough


b. What are the different types of maintenance?

c. what are the design principles?


d. Explain the tracking and scheduling.


e. Explain the scenario-based model.

f. Compare Scrum and Kanban.
