1.

Totally be based on your syllabus right now as we are not conducting practical exams
practical point of view questions will be there mostly based on your diagrams
2. Which notations will be used for a particular diagram
3. Include and extend relationship what is the difference between them and how is it used
4. Difference Between sequence diagram and collaboration diagram
5. which type of relationship can be used in A Class diagram
6. From first chapter any process models can be asked
7. Difference between two models
8. When to go for a specific model
9. Questions based on risk what are the different categories of risk
10. what is the impact of risk
11. Estimation techniques like a loc,cocomo
12. Special question can be on COCOMO on how the cost can be estimated using COCOMO
13. Explain procedure how COCOMO model is used
14. In design part there are some golden rules for designing so those questions can be asked
15. Different types of testing strategies
16. Black box testing integration testing white box testing
17. Reverse Engineering re-engineering fpr
18. Maintenance type of maintenance
19. Software configuration management
20. Process for software configuration management
21. How version management can be Done
22. How change control can be done
23. What is baseline what is ECO
24. SCM repository what is the use of SCM repository
25. What are the different CMM levels and what is the difference between each level
Vatsal Gada

Cocomo Model
Calculate - effort, development time, average staff size & productivity

There are 3 types of cocomo models:

Basic

Intermediate

Complete/detailed

These 3 models can be applied to three classes of software projects:

Proj Size Nature innovation deadline

organic 2-50 Small size, little Not tight

experienced

semi-detached 50-300 medium medium medium

embedded >300 large significant tight

Basic Model:

Does not account for differences in hardware constraints, personnel quality, and
experience, use of modern tools and techniques.

Formula:

Effort Applied (E) = (ab) * KLOC(bb) in person-month

Development Time (D) = (cb) * E(db)in month

People required = E/D in person

Intermediate COCOMO :

This model computes software development effort as a function of program size and a
set of ‘cost drivers’ that include subjective assessments of product, hardware,
personnel, and project attributes.

Formula:

Effort Applied = (ai) * KLOC(bi) * EAF(effort adjustment factor) in person-month

Development Time = (cb) * E(db)in month

People required = E/D in person

 Advantages Disadvantages

● Based on history ● Must know the cost drivers

● Easy to use ● Must be able to predict project
● Repeatable size
● Ignores requirements volatility
● Well Documented
● Ignores documentation

COCOMO II

The COCOMO II application composition model uses object points –an indirect
software measure that is computed using counts of the number of 1) screens 2) reports
and 3) components likely to be required to build the application.

1.Each object instance is classified into one of three complexity levels

2.Once the complexity is determined, the number of screens, reports and components
are weighted according to the table below

LOC
Line of code: Any line of program code excluding blank spaces and comments,
regardless of no. of statements

Includes all lines including header, declarations, executable and non executable code

Advantage:

● Size estimation
● Easy to count and calculate from code

Disadvantage:

● Language and technology-dependent

● Bad software design causes excessive loc
Golden Design Rules
1. Strive for Consistency

2. Visibility of system status or Offer informative feedback

3. Match between system and the real world of Design dialog to yield closure

4, User control and freedom or Permit easy reversal of actions

5, Error Prevention and Simple Error Handling

6. Reduce short-term memory load or Recognition rather than recall

7. Enable frequent users to use shortcuts

8, Aesthetic and Minimalist design

9. Help users recognize, diagnose, and recover from errors

10. Help and documentation

What is Black Box testing?

In Black-box testing, a tester doesn't have any information about the internal working
of the software system. Black box testing is a high level of testing that focuses on the
behavior of the software. It involves testing from an external or end-user perspective.
Black box testing can be applied to virtually every level of software testing: unit,
integration, system, and acceptance.

What is White Box testing?

White-box testing is a testing technique that checks the internal functioning of the
system. In this method, testing is based on coverage of code statements, branches,
paths or conditions. White-Box testing is considered as low-level testing. It is also
called glass box, transparent box, clear box or code base testing. The white-box
Testing method assumes that the path of the logic in a unit or program is known.
Reengineering

It is an activity that improves one’s understanding of software or/and to improve the

software itself for better maintainability, reusability, and evolvability.

Software re-engineering is used to update the existing software in the new form
product so that the software product will provide high performance, and improve the
functionality of the system.

Software Reverse Engineering (g)

is a process of recovering the design, requirement specifications and functions of a

product from an analysis of its code. It builds a program database and generates
information from this.

The purpose of reverse engineering is to facilitate the maintenance work by improving

the understandability of a system and to produce the necessary documents for a
legacy system.

● Reverse Engineering Goals:

● Cope with Complexity.
● Recover lost information.
● Detect side effects.
● Synthesize higher abstraction.
● Facilitate Reuse.

Software Maintenance

A process of modifying a software system after delivery to correct faults and improve
on other attributes

Types:

● Corrective: taking existing code and correcting a fault that deviates from its
original document requirements
● Adaptive: Adding new features and functionalities to existing code
 ● Perfective: updates are done in order to keep the software usable over a long
period of time, typically to improve the maintainability of code
● Inspection: usually made as a result of code inspection to reduce the likelihood
of failure

Quick fix - as the name suggests, not good for large companies

Iterative enhancement model - analyze existing system and improve

Full reuse - reuse for new system, identify what can work and integrate in new

Boehn’s - cycle- management decision - approved changes done - new proposed

changes

Software configuration management

SCM is a system for managing all versions/evolutions of software products both during the
initial stages of development and during all stages of maintenance

Why:

There are multiple people working on software that is continually updating

It may be a case where multiple version, branches, authors are involved in a software
config project, and the team is geographically distributed and works concurrently

Process:

(1) To identify all of the respective items which jointly define the software configuration,

(2) To manage changes applied to these items,

(3) To ease the building of different versions of an application, and

(4) To make sure that there is consistency in software quality as the configuration evolves

time.

Version control:

Version control, also known as source control, is the practice of tracking and managing
changes to software code.

Version control systems are software tools that help software teams manage changes to
source code over time.

Change control:

The change control process in project management ensures that each change proposed
during a project is adequately defined, reviewed, and approved before implementation.
The change control process helps avoid unnecessary changes that might disrupt services
and also ensures the efficient use of resources.

Change control contains five stages:

● Proposing a Change
● Summary of Impact
● Decision
● Implementing a Change
● Closing a Change

Baseline
A baseline is a reference point in the software development life cycle marked by the
completion and formal approval of a set of predefined work products

The purpose of a baseline is to provide:

Measurable progress points within the system development lifecycle

A stable reference for future work

ECO

An engineering change order (ECO) is a document that specifies either new product
design details or proposed changes to existing products. ECOs provide a list of all the
components, assemblies, and other documents that are affected.

SCM repository

Is a group of mechanisms and data structure that enables software team to deal with
modifications in an efficient manner

Takes care of data integrity, sharing, and integration

Provides hub purpose of the integration of different software tools

Capability Maturity Model

Capability Maturity Model is used as a benchmark to measure the maturity of an

organization's software process.

Levels:

Level One: Initial - The software process is characterized as inconsistent, and occasionally
even chaotic.

Level Two: Repeatable - This level of Software Development Organization has a basic and
consistent project management processes to track cost, schedule, and functionality.
Level Three: Defined - The software process for both management and engineering
activities are documented, standardized, and integrated into a standard software process
for the entire organization and all projects across the organization use an approved,
tailored version of the organization's standard software process for developing,testing and
maintaining the application.

Level Four: Managed - Management can effectively control the software development
effort using precise measurements. At this level, organization set a quantitative quality goal
for both software process and software maintenance.

Level Five: Optimizing - The Key characteristic of this level is focusing on continually
improving process performance through both incremental and innovative technological
improvements.