UT-191-250-0017

BCA-HC-3016 (Software Engineering)

Q.No.1
a)What do you mean by software lifecycle model? Explain waterfall model.

Answer:

A software development life cycle (SDLC) model is a conceptual framework describing all activities in a
software development project from planning to maintenance. This process is associated with several
models, each including a variety of tasks and activities.
Software development is a cumbersome activity requiring proper identification of requirements, their
implementation, and software deployment. However, the activities do not end there. After the distribution
of the software, proper maintenance has to be provided in a timely manner.
This term is also known as software development process model.
The major software development activities include:
•Requirement extraction
•Software description
•Abstract system representation
•Client requirements
•Code testing
•Documentation of the internal design
•Maintenance
The above development process is streamlined by a series of models. The development team selects the
best suitable model.
The Waterfall model is the earliest SDLC approach that was used for software development.
Waterfall Model - Design
Waterfall approach was first SDLC Model to be used widely in Software Engineering to ensure success of
the project. In "The Waterfall" approach, the whole process of software development is divided into
separate phases. In this Waterfall model, typically, the outcome of one phase acts as the input for the next
phase sequentially.
The following illustration is a representation of the different phases of the Waterfall Model.
Requirement Gathering and analysis − All possible requirements of the system to be developed are
captured in this phase and documented in a requirement specification document.

System Design − The requirement specifications from first phase are studied in this phase and the system
design is prepared. This system design helps in specifying hardware and system requirements and helps in
defining the overall system architecture.

Implementation − With inputs from the system design, the system is first developed in small programs
called units, which are integrated in the next phase. Each unit is developed and tested for its functionality,
which is referred to as Unit Testing.

Integration and Testing − All the units developed in the implementation phase are integrated into a system
after testing of each unit. Post integration the entire system is tested for any faults and failures.

Deployment of system − Once the functional and non-functional testing is done; the product is deployed in
the customer environment or released into the market.

Maintenance − There are some issues which come up in the client environment. To fix those issues, patches
are released. Also to enhance the product some better versions are released. Maintenance is done to deliver
these changes in the customer environment.

All these phases are cascaded to each other in which progress is seen as flowing steadily downwards (like a
waterfall) through the phases. The next phase is started only after the defined set of goals are achieved for
previous phase and it is signed off, so the name "Waterfall Model". In this model, phases do not overlap.

b) What is SRS? Explain the characteristics & organization of SRS.

Answer:

Software requirement specification (SRS) is a document that completely describes what the proposed
software should do without describing how software will do it. The basic goal of the requirement phase
is to produce the SRS, Which describes the complete behavior of the proposed software. SRS is also
helping the clients to understand their own needs.
Software SRS establishes the basic for agreement between the client and the supplier on what the
software product will do.
Software requirements specification should be accurate, complete, efficient, and of high quality, so that
it does not affect the entire project plan. An SRS is said to be of high quality when the developer and
user easily understand the prepared document. Other characteristics of SRS are discussed below.
Correctness: SRS is correct when all user requirements are stated in the requirements document. The
stated requirements should be according to the desired system. This implies that each requirement is
examined to ensure that it (SRS) represents user requirements. Note that there is no specified tool or
procedure to assure the correctness of SRS. Correctness ensures that all specified requirements are
performed correctly.
Unambiguous: SRS is unambiguous when every stated requirement has only one interpretation. This
implies that each requirement is uniquely interpreted. In case there is a term used with multiple
meanings, the requirements document should specify the meanings in the SRS so that it is clear and
easy to understand.
Complete: SRS is complete when the requirements clearly define what the software is required to do.
This includes all the requirements related to performance, design and functionality.
Ranked for importance/stability: All requirements are not equally important, hence each
requirement is identified to make differences among other requirements. For this, it is essential to
clearly identify each requirement. Stability implies the probability of changes in the requirement in
future.
Modifiable: The requirements of the user can change, hence requirements document should be
created in such a manner that those changes can be modified easily, consistently maintaining the
structure and style of the SRS.
Traceable: SRS is traceable when the source of each requirement is clear and facilitates the reference
of each requirement in future. For this, forward tracing and backward tracing are used. Forward
tracing implies that each requirement should be traceable to design and code elements. Backward
tracing implies defining each requirement explicitly referencing its source.
Verifiable: SRS is verifiable when the specified requirements can be verified with a cost-effective
process to check whether the final software meets those requirements. The requirements are verified
with the help of reviews. Note that unambiguity is essential for verifiability.
Consistent: SRS is consistent when the subsets of individual requirements defined do not conflict
with each other. For example, there can be a case when different requirements can use different
terms to refer to the same object. There can be logical or temporal conflicts between the specified
requirements and some requirements whose logical or temporal characteristics are not satisfied. For
instance, a requirement states that an event ‘a’ is to occur before another event ‘b’. But then another
set of requirements states (directly or indirectly by transitivity) that event ‘b’ should occur before
event ‘a’.

The organisation of SRS is depends of following points.

Functionality: It should be separate from implementation.
Analysis model: It should be developed according to the desired behavior of a system. This should
include data and functional response of a system to various inputs given to it.
Cognitive model: It should be developed independently of design or implementation model. This
model expresses a system as perceived by the users.
The content and structure of the specification: It should be flexible enough to accommodate changes.
Specification: It should be robust. That is, it should be tolerant towards incompleteness and
complexity.
The information to be included in SRS depends on a number of factors, for example, the type of
software being developed and the approach used in its development. If software is developed using
the iterative development process, the requirements document will be less detailed as compared to
that of the software developed for critical systems. This is because specifications need to be very
detailed and accurate in these systems. A number of standards have been suggested to develop a
requirements document. However, the most widely used standard is by IEEE, which acts as a general
framework. This general framework can be customized and adapted to meet the needs of a particular
organization.
 Q.No.2
a)Explain in detail about Coupling and Cohesion.
Answer:
Coupling is the measure of the degree of interdependence between the modules. A good software will have
low coupling.

Types of Coupling:

Data Coupling: If the dependency between the modules is based on the fact that they communicate by
passing only data, then the modules are said to be data coupled. In data coupling, the components are
independent to each other and communicating through data. Module communications don’t contain
tramp data. Example-customer billing system.
Stamp Coupling In stamp coupling, the complete data structure is passed from one module to another
module. Therefore, it involves tramp data. It may be necessary due to efficiency factors- this choice made
by the insightful designer, not a lazy programmer.

Control Coupling: If the modules communicate by passing control information, then they are said to be
control coupled. It can be bad if parameters indicate completely different behavior and good if parameters
allow factoring and reuse of functionality. Example- sort function that takes comparison function as an
argument.

External Coupling: In external coupling, the modules depend on other modules, external to the software
being developed or to a particular type of hardware. Ex- protocol, external file, device format, etc.

Common Coupling: The modules have shared data such as global data structures. The changes in global
data mean tracing back to all modules which access that data to evaluate the effect of the change. So it has
got disadvantages like difficulty in reusing modules, reduced ability to control data accesses and reduced
maintainability.

Content Coupling: In a content coupling, one module can modify the data of another module or control
flow is passed from one module to the other module. This is the worst form of coupling and should be
avoided.
Cohesion is a measure of the degree to which the elements of the module are functionally related. It is the
degree to which all elements directed towards performing a single task are contained in the component.
Basically, cohesion is the internal glue that keeps the module together. A good software design will have high
cohesion.

Types of Cohesion:

Functional Cohesion: Every essential element for a single computation is contained in the component. A
functional cohesion performs the task and functions. It is an ideal situation.

Sequential Cohesion: An element outputs some data that becomes the input for other element, i.e., data flow
between the parts. It occurs naturally in functional programming languages.

Communicational Cohesion: Two elements operate on the same input data or contribute towards the same
output data. Example- update record in the database and send it to the printer.

Procedural Cohesion: Elements of procedural cohesion ensure the order of execution. Actions are still weakly
connected and unlikely to be reusable. Ex- calculate student GPA, print student record, calculate cumulative
GPA, print cumulative GPA.

Temporal Cohesion: The elements are related by their timing involved. A module connected with temporal
cohesion all the tasks must be executed in the same time-span. This cohesion contains the code for initializing
all the parts of the system. Lots of different activities occur, all at unit time.

Logical Cohesion: The elements are logically related and not functionally. Ex- A component reads inputs from
tape, disk, and network. All the code for these functions is in the same component. Operations are related, but
the functions are significantly different.

Coincidental Cohesion: The elements are not related(unrelated). The elements have no conceptual relationship
other than location in source code. It is accidental and the worst form of cohesion. Ex- print next line and
reverse the characters of a string in a single component.
b) Describe the Software Development Process in brief.
Answer:
A software development process or life cycle is a structure imposed on the development of a software product.
There are several models for such processes, each describing approaches to a variety of tasks or activities that take
place during the process.

Processes
More and more software development organizations implement process methodologies.

The Capability Maturity Model (CMM) is one of the leading models. Independent assessments can be used to
grade organizations on how well they create software according to how they define and execute their processes.

There are dozens of others, with other popular ones being ISO 9000, ISO 15504, and Six Sigma.

Process Activities/Steps
Software Engineering processes are composed of many activities, notably the following:

Requirements Analysis
Extracting the requirements of a desired software product is the first task in creating it. While customers probably
believe they know what the software is to do, it may require skill and experience in software engineering to
recognize incomplete, ambiguous or contradictory requirements.
Specification
Specification is the task of precisely describing the software to be written, in a mathematically rigorous way. In
practice, most successful specifications are written to understand and fine-tune applications that were already
well-developed, although safety-critical software systems are often carefully specified prior to application
development. Specifications are most important for external interfaces that must remain stable.
Software architecture
The architecture of a software system refers to an abstract representation of that system. Architecture is concerned
with making sure the software system will meet the requirements of the product, as well as ensuring that future
requirements can be addressed.
Implementation
Reducing a design to code may be the most obvious part of the software engineering job, but it is not necessarily
the largest portion.
Testing
Testing of parts of software, especially where code by two different engineers must work together, falls to the
software engineer.
Documentation
An important task is documenting the internal design of software for the purpose of future maintenance and
enhancement.
Training and Support
A large percentage of software projects fail because the developers fail to realize that it doesn't matter how much
time and planning a development team puts into creating software if nobody in an organization ends up using it.
People are occasionally resistant to change and avoid venturing into an unfamiliar area, so as a part of the
deployment phase, its very important to have training classes for the most enthusiastic software users (build
excitement and confidence), shifting the training towards the neutral users intermixed with the avid supporters,
and finally incorporate the rest of the organization into adopting the new software. Users will have lots of
questions and software problems which leads to the next phase of software.
Maintenance
Maintaining and enhancing software to cope with newly discovered problems or new requirements can take far
more time than the initial development of the software. Not only may it be necessary to add code that does not fit
the original design but just determining how software works at some point after it is completed may require
significant effort by a software engineer. About 60% of all software engineering work is maintenance, but this
statistic can be misleading. A small part of that is fixing bugs. Most maintenance is extending systems to do new
things, which in many ways can be considered new work.