ASSIGNMENT NO.

---1
On
Software engineering

Submitted To:-
Lect Amandeep sir
Submitted by

Name:-Prashant Raghav
Roll no.:- RE3004B39
Section:- E3004 Group:- 2
 HOME WORK-1\

CAP324- Software Engineering

PART –A

1. Take a suitable example to develop a software and implement

the waterfall

Model technique in it to develop the software ?

Ans:

The waterfall model shows a process, where developers are to follow these
phases in order:

1. Requirements specification (Requirements analysis)

2. Software Design
3. Integration
4. Testing (or Validation)
5. Deployment (or Installation)
6. Maintenance

In a strict Waterfall model, after each phase is finished, it proceeds to the

next one. Reviews may occur before moving to the next phase which
allows for the possibility of changes (which may involve a formal change
control process). Reviews may also be employed to ensure that the phase
is indeed complete; the phase completion criteria are often referred to as a
"gate" that the project must pass through to move to the next phase.
Waterfall discourages revisiting and revising any prior phase once it's
complete. This "inflexibility" in a pure Waterfall model has been a source of
criticism by supporters of other more "flexible" models.
The waterfall model proceeds from one phase to the next in a sequential
manner. For example, one first completes requirements specification,
which after sign-off are considered "set in stone." When requirements are
completed, one proceeds to design. The software in question is designed
and a blueprint is drawn for implementers (coders) to follow—this design
should be a plan for implementing the requirements given. When the
design is complete, an implementation of that design is made by coders.
Towards the later stages of this implementation phase, separate software
components produced are combined to introduce new functionality and
reduced risk through the removal of errors.

2. Differentiate between RAD and component based development

by taking some suitable example?

Ans:

RAD (Rapid Action Development)

The RAD model is linear sequential software development process that

emphasizes an extremely short development cycle. The RAD model is a
high speed adaption of the linear sequential model in which rapid
development is achieved by using component based construction
approach. It has following phases

• Business modeling
• Data modeling
• Process modeling
• Application generation
• Testing and Turnover

Component Based Development

Commercial off - the – shelf (COTS) software components, developed by

vendors who offer them as products, provides targeted functionality with
well-defined interfaces that enable the component to be integrated into the
software that is to be built. The component based development model
incorporates many of the characteristics of the spiral model. It is
evolutionary in nature, demanding an iterative approach to the creation of
software. However, the component based development model construct
applications from pre-packaged software components.
Component based development (CBD) consisting of developing software
applications from loosely coupled components has the following distinct
advantages:

1. Software Reuse - Encourages higher level of software reuse.

2. Simplifies Testing - Allows testing to be carried out by first
testing each of the components before testing the assembly of
components.
3. Simplifies system maintenance and modification - Since
each of the components are loosely coupled you are free to upgrade
and/or add components as needed without effecting other parts of
the system.
4. Higher Quality - Since a component can be built and then
continuously improved upon by an expert or organization the quality
of a component based application will improve over time.

3. What do we look for when choosing someone to lead a software

project? Justify your statement by giving some example.

Ans:

Project management is a people intensive activity, and for this reason,

competent practitioners often make poor team leaders. They simply
don’t have the right mix of people skills. And yet, as Edgemon states
unfortunately and all too frequently it seems individual just fall into a
project manager role and become accidental project managers.

Model of leadership

Motivation : The ability to encourage (by “push or pull”) technical

people to produce to their best ability.

Organization : The ability to mold existing processes (or invent new

ones) that will enable the initial concept to be translated into a final
product.
Ideas of innovation : The ability to encourage people to create and feel
creative evan when they must work within bounds established for a
particuler software product or application.

Problem Solving :

Managerial identity : A good project manager must take charge of the

project. She must have the confidence to assume control when
necessary and the assurance to all good technical people to follow their
instinct.

Achievement : A complete manager must reward initiative and

accomplishment to optimize the productivity of a project teem. She must
demonstrate through own action that controlled risk taking will not be
punished..

Influence and team building : An effective project manager must be

able to read people she must be able to understand verbal and
nonverbal signals and react to the needs of the people sending the
signal. The manager must remain under control in high stress situations.

PART-B
 1. What guidelines should be applied when we collect software
metrics ? Give

suitable examples.

Ans:- There are 100 of metrics have been proposed for computer
software, but not all provide practical support to the software
engineer. There are defines a set of attributes that should be
encompassed by effective software metrics.

• Simple and computable:- it should be relatively easy to learn

how to derive the metrics, and its computation should not
demand inordinate effort or time.

• Empirically and intuitively persuasive:- the metrics should

satisfy the engineer’s intuitive notion about the product attribute
under consideration.

• Consistent and objective:- The metrics should always yield

result that are unambiguous.

• Consistent in its use of unit and dimension:- the mathematical

computation of the metric should use measure that do not lead
to bizarre combinations of unit.

• Programming language independent:- metrics should be based

on the requirement model, the design model, or the structure of
the program itself. They should not be dependent on the
vagaries of programming language syntax or semantics.

• An effective mechanism for high-quality feedback:- that is the

metrics should provide you with information that can lead to a
higher-quality end product.

Although most of the metrics satisfy these attribute, some commonly used
metrics may fail to satisfy one or two of them. An example is the function
point- a measure of the “functionality” delivered by the software. It can be
argued that the consistent and objective attribute fails because an
independent 3rd party may not be able to derive the same function point
value as a colleague using the same information about the software, thus
we reject the FP.

2. How do we size the software that we are planning to build ? Justify

your

statements by giving some suitable examples.

Ans:- There are some approaches to the sizing problem

• “Fuzzy logic” sizing:- this approach uses the approximate

reasoning techniques that are the cornerstone of fuzzy logic. To
apply this approach, the planner must identify the type of
application, establish its magnitude on a qualitative scale, and
then refine the magnitude within the original range.

• Function point sizing:- the planner develops estimates of the

information domain characteristics.

• Standard component sizing:- software is composed of a

number of different “standard component” that are generic to a
particular application area.

• Change sizing:- this approach is used when a project

encompasses the use of existing software that must be
modified in some way as part of a project.

3. With the help of examples explain that ‘what benefits does metrics
baseline

provide to a software engineer ?’

Ans:

By establishing a metrics baseline benefits can be k obtained that at

the process, project, and product levels. Yet the information that is
collected need not be fundamentally different. The matrices baseline
consist of data collected form past software development.
To be an effective aid in process improvement and/or cost and effort
estimation, baseline data must have the following attributes.

1.) Data must be reasonably accurate – “guestimates” about past

projects are to be avoided.

2.) Data should be collected for as many projects as possible.

3.) Measures must be consistent (for example, a line of code must be

interpreted consistently across all projects for which data are
collected.)

4.) Application should be similar to work that is to be estimated – it

makes little sense to use a baseline for batch information systems
work to estimate a real-time embedded application.