Part A

Q1. “Software cost and effort estimation will never be an exact science. Too many
variables— human, technical, environmental, political—can affect the ultimate
cost of software and effort applied to develop it.” Do you support this statement?
Justify your answer with a suitable example.

Ans: Yes, it’s absolutely fitting in the box i.e. it’s true because the management of
software begins with a set of activities that are collectively called project planning. From
the size estimate, determine the effort needed. From the effort estimate determine
project duration, and cost.
Three main approaches to estimation: Empirical Heuristic Analytical Empirical
techniques an educated guess based on past experience. Heuristic techniques assume
that the characteristics to be estimate Analytical techniques derive the required results
starting from certain simple assumptions. Hardware and software costs Travel and
training costs Effort costs salaries of engineers involved in the project.

When the project is initiated we have only some idea of the classes of data the system
will get and produce and the major functionality of the system. There is a great deal of
uncertainty about the actual specifications of the system. Estimates at this phase of the
project can be off by as much as a factor of four from the actual final cost. As we specify
the system more fully and accurately, the uncertainties are reduced and more accurate
cost estimates can be made. For example, once the requirements are completely
specified, more accurate cost estimate s can be made compared to the estimates after
the feasibility study. Once the design is complete, the estimates can be made still more
accurately.

Q2. “Before the project can begin, the manager and the software team must
estimate the work to be done, the resources that will be required, and the time
that will elapse from start to finish.”

Ans: To complete the project successfully the mentioned criterions must be followed as
size increases, the interdependency among various elements of the software grows
rapidly. The availability of historical information has a strong influence on estimation
risk. Risk is measured by the degree of uncertainty in the quantitative estimates
established for resources, cost, and schedule.Estimation gives you a fair idea of the
size of the project. About size to estimate the cost, effort, and duration of the project.
This further helps plan for resources and schedule the project. Estimate the size of the
product: - As size increases, the interdependency among various elements of the
software grows rapidly. Thus size estimation is very important.
Estimate the effort: - It tells about how many man per month are required for the
development of software.
Q3. What is the difference between a SCM audit and a formal technical review?
Can their functions be folded into one review? What are the pros and cons?

Ans: The SCM audit is conducted separately by the quality assurance group.
Reviewers assess the SCI to determine consistency with other SCIs, omissions, or
potential side effects. A formal technical review should be conducted for all but the most
trivial changes. A software configration audit complements the formal technical review
by assessing a configuration object for characteristics that are generally not considered
during review.

Prons and Cons: - The extent to which an item satisfies the required functional and
physical characteristics. Informal audits of this type can be conducted at key points in
the life cycle is determined by The software configuration auditing activity. Two types of
formal audits might be required by the governing contract (for example, in contracts
covering critical software): the Functional Configuration Audit (FCA) and the Physical
Configuration Audit (PCA). Successful completion of these audits can be a prerequisite
for the establishment of the product baseline.

Part B
Q4. Discuss in detail about Putnam allocation model elaborate by providing some
example.

Ans: The Putnam model describes the time and effort required to finish a software
project of specified size. SLIM (Software Life cycle Management) is the name given by
Putnam to the proprietary suite of tools developed based on his model. It was created
by Lawrence Putnam Sr. Empirical models work by collecting software project data.

E = [LOC * B0.333/P]3 (1/t4)

Where, E = effort in person-months or person-years

t = project duration in months or years

B = “special skills factor”

P = “productivity parameter” that reflects

Q5. Elaborate on the issues that relates to the Risk analysis and Risk
management of any software development process.

Ans: Risk is a potential problem that might happen or might not. Lots of things can go
wrong, and frankly, many often do. It’s for this reason that being prepared
,understanding the risks and taking proactive measures to avoid or manage them is a
key element of good software project management regardless of outcome it is good
idea to identify it, acess its probability of occurring and its impact. Risk management is
followed by coordinated and economical application of resources to minimize, monitor,
and control the probability and/or impact of unfortunate events] or to maximize the
realization of opportunities.

Risks can come from uncertainties in: -

• Financial markets

• Project failures.

• Product Size

• Business Impact

• Customer-Related Needs

• Processing

• Technical issues

• Staff size

Risk analysis is figuring out what the risks are and what to focus on. It includes

• Risk assessment

• Risk characterization

• Risk communication

• Risk management

• Policy relating to risk.

Risk Assessment is also called as Security risk analysis. It involves identifying the most
probable threats to an organization and analyzing the related vulnerabilities of the
organization to these threats.
Risk Management is a process of coming up with techniques and strategies to mitigate
the highest ordered risks, implementing the strategies to resolve the high order risks
factors, monitoring the effectiveness of the strategies and the changing levels of risk
throughout the project.

Q6. “Cohesion & coupling in the software pay important role in the design phase
of the software development process.” Elaborate it using some suitable
examples.

Ans: Cohesion is a measure of the relative functional strength of a module while

Coupling is a measure of the relative interdependence among modules.

Cohesion:

Cohesion is a natural extension of the information hiding concept. Cohesion may be

represented as a "spectrum." We always strive for high cohesion, although the mid-
range of the spectrum is often acceptable. The scale for cohesion is nonlinear. That is,
low-end cohesiveness is much "worse" than middle range, which is nearly as "good" as
high-end cohesion. In practice, a designer need not be concerned with categorizing
cohesion in a specific module. Rather, the overall concept should be understood and
low levels of cohesion should be avoided when modules are designed.

Coupling:

Coupling is a measure of interconnection among modules in a software structure.

Coupling depends on the interface complexity between modules, the point at which
entry or reference is made to a module, and what data pass across the interface. In
software design, we strive for lowest possible coupling. Simple connectivity among
modules results in software that is easier to understand and less prone to a "ripple
effect", caused when errors occur at one location and propagate through a system
.

This figure provides examples of different types of module coupling. Modules a and d
are subordinate to different modules. Each is unrelated and therefore no direct coupling
occurs. Module c is subordinate to module a and is accessed via a conventional
argument list, through which data are passed. As long as a simple argument list is
present (i.e., simple data are passed; a one-to-one correspondence of items exists), low
coupling (called data coupling) is exhibited in this portion of structure. A variation of data
coupling, called stamp coupling is found when a portion of a data structure (rather than
simple arguments) is passed via a module interface. This occurs between modules b
and a. At moderate levels, coupling is characterized by passage of control between
modules. Control coupling is very common in most software designs and is shown in
Figure where a “control flag” (a variable that controls decisions in a subordinate or super
ordinate module) is passed between modules d and e.