August 2010

Master of Computer Application (MCA) – Semester 3

MC0071 – Software Engineering– 4 Credits
(Book ID: B0808 & B0809)
Assignment Set – 1 (60 Marks)

Answer all Questions Each question carries TEN marks

Book ID: B0808

1. Describe the following Software Development Models:
A) The concurrent development model, sometimes called concurrent engineering

The concurrent process model can be represented schematically as a series of major

technical activities, tasks, and their associated states. For example, the engineering

activity defined for the spiral model is accomplished by invoking the

following tasks: prototyping and/or analysis modeling, requirements specification,

and design.

The activity-analysis-may be in any one of the states noted

at any given time. Similarly, other activities (e.g., design or customer communication)

can be represented in an analogous manner. All activities exist concurrently but

reside in different states. For example, early in a project the customer communication

activity has completed its first iteration and exists in the awaiting changes state. The analysis
activity (which existed in the none state while initial customer communication was completed)
now makes a transition into the under development state. If, however, the customer indicates
that changes in requirements must be made, the analysis activity moves from the under
development state into the awaiting changes state.

The concurrent process model defines a series of events that will trigger transitions

from state to state for each of the software engineering activities.

B) Hacking:-
Hacking refers to the re-configuring or re-programming of a system to function in ways not
facilitated by the owner, administrator, or designer. The term(s) have several related meanings
in the technology and computer science fields, wherein a "hack" may refer to a clever or quick
fix to a computer program problem, or to what may be perceived to be a clumsy or inelegant
(but usually relatively quick) solution to a problem, such as a "kludge".

The terms "hack" and "hacking" are also used to refer to a modification of a program or device
to give the user access to features that were otherwise unavailable, such as by circuit bending.
It is from this usage that the term "hacking" is often used to refer to more nefarious criminal
uses such as identity theft, credit card fraud or other actions categorized as computer crime.

2. Explain the Software Architectural design.

The software architecture discipline is centered on the idea of reducing complexity through
abstraction and separation of concerns. To date there is still no agreement on the precise
definition of the term “software architecture”.

As a maturing discipline with no clear rules on the right way to build a system, designing
software architecture is still a mix of art and science. The “art” aspect of software architecture
is because a commercial software system supports some aspect of a business or a mission.
How a system supports key business drivers is described via scenarios as non-functional
requirements of a system, also known as quality attributes, determine how a system will
behave.[6] Every system is unique due to the nature of the business drivers it supports, as
such the degree of quality attributes exhibited by a system such as fault-tolerance, backward
compatibility, extensibility, reliability, maintainability, availability, security, usability, and such
other –ilities will vary with each implementation. To bring a software architecture user's
perspective into the software architecture, it can be said that software architecture gives the
direction to take steps and do the tasks involved in each such user's speciality area and
interest e.g. the stakeholders of software systems, the software developer, the software
system operational support group, the software maintenance specialists, the deployer, the
tester and also the business end user[citation needed]. In this sense software architecture is
really the amalgamation of the multiple perspectives a system always embodies. The fact that
those several different perspectives can be put together into a software architecture stands as
the vindication of the need and justification of creation of software architecture before the
software development in a project attains maturity.
3. Describe the following system models giving appropriate real time examples:

A) Data Flow Models:-

In the late 1970s data-flow diagrams (DFDs) were introduced and popularized for structured
analysis and design (Gane and Sarson 1979). DFDs show the flow of data from external
entities into the system, showed how the data moved from one process to another, as well as
its logical storage. There are only four symbols:

Squares representing external entities, which are sources or destinations of data.

Rounded rectangles representing processes, which take data as input, do something to it, and
output it.

Arrows representing the data flows, which can either be electronic data or physical items.

Open-ended rectangles representing data stores, including electronic stores such as

databases or XML files and physical stores such as or filing cabinets or stacks of paper.

There are several common modeling rules that I follow when creating DFDs:

All processes must have at least one data flow in and one data flow out.

All processes should modify the incoming data, producing new forms of outgoing data.

Each data store must be involved with at least one data flow.

Each external entity must be involved with at least one data flow.

A data flow must be attached to at least one process.

B) Semantic Models:-
The use of a semantic model as a fundamental step in the data warehouse development
process can serve as a keystone for understanding requirements, the design of the
subsequent data models, and as a link between the reporting tool interface and the physical
data models. Although not as famous as its logical or physical data model cousins, the
semantic model deserves generally greater consideration because of its unyielding focus on
the user perspective. When built correctly, the semantic model is the user's perspective of the
data-and what could be more important?
In a general sense, semantics is the study of meanings-of the message behind the words.
"Semantic" in the context of data and data warehouses means "from the user's perspective." It
is the data in context-where the meaning is. "Information" is also often defined as "data in
context." "Semantic" therefore, while not synonymous with information, carries with it the same
sense of data at work, or data in the worker's hands.

Semantic data elements are deceptively similar to the entities and attributes we find in a
logical or physical data model. They are things like "customer," "product," "credit limit," "net
sales," and so forth. What the semantic modeler must address however, is the context of the
term-the data element- and how it relates to the data elements as present in the computing
systems data stores. For example, is a customer an individual-the Purchasing Agent- or a
company? Must a customer have actually purchased a product, or can a customer also be
someone who is in the market for a (the) product? What in some contexts might be called a
"prospect" might be called a "customer" in others. Is a customer a wholesaler or is the end
consumer the customer? Is the wholesaler's customer also called a customer?

The answer to these questions is likely to be "it depends." And that is the correct answer,
because it does depend. It depends on who is asking and why. ABC company's sales
department may draw a clear line between customers (buyers) and prospects. ABC's
marketing department may simply use "customer" to refer to those participating in the market,
whether or not they've actually bought ABC's product.

The semantic modeler must drill down and capture the nuance of each perspective and must
struggle to work with the business users to develop a naming convention or syntax that
provides clarity. All perspectives are represented in the semantic model.

C) Object Models
Three concepts are critical to understanding object models. They are:

1. Data abstraction

2. Encapsulation

3. Inheritance

Data abstraction is the process of distilling data down to its essentials. In an object schema,
the abstract data model is implemented as a graph. The following figure shows such a graph
structure for a genealogical database. For more information on data abstraction, see the items
under "more detail" below. For another example of data abstraction,
Encapsulation is the object model concept of including processing or behavior with the object
instances defined by the class. Encapsulation allows code and data to be packaged together.

The definition of methods for a class is an integral part of encapsulation. A method is

programming code that performs the behavior an object instance can exhibit. Calculating the
age of a person would be an example of such behavior. The figure shows a way of looking at
encapsulating the age method with an instance object. The code for the age method is
"attached" to or encapsulated with the object rather than part of the application.

Inheritance in the object model is a means of defining one class in terms of another. This is
common usage for most of us. For example, a conifer is a type of tree. There are certain
characteristics that are true for all trees, yet there are specific characteristics for conifers.

Note that in an object model, there is no distinction in usage between system pre-defined
types and user-defined types. This is known as extensibility. So it is possible to define a type
as a sub-type of a system type or as a sub-type of a user-define type.

Book ID: B0809

4. Describe the following software life cycle models:
A) Waterfall Model:-
The waterfall model is a sequential software development process, in which
progress is seen as flowing steadily downwards (like a waterfall) through the
phases of Conception, Initiation, Analysis, Design, Construction, Testing and
Maintenance.
The waterfall development model originates in the manufacturing and
construction industries; highly structured physical environments in which after-
the-fact changes are prohibitively costly, if not impossible. Since no formal
software development methodologies existed at the time, this hardware-oriented
model was simply adapted for software development.
In Royce's original waterfall model, the following phases are followed in order:
Requirements specification
1. Design
2. Construction (AKA implementation or coding)
3. Integration
4. Testing and debugging (AKA Validation)
5. Installation
6. Maintenance
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.
Thus the waterfall model maintains that one should move to a phase only when
its preceding phase is completed and perfected. However, there are various
modified waterfall models (including Royce's final model) that may include slight
or major variations upon this process.

B) Incremental Model
The incremental build model is a method of software development where the
model is designed, implemented and tested incrementally (a little more is added
each time) until the product is finished. It involves both development and
maintenance. The product is defined as finished when it satisfies all of its
requirements. This model combines the elements of the waterfall model with the
iterative philosophy of prototyping.
The product is decomposed into a number of components, each of which are
designed and built separately (termed as builds). Each component is delivered to
the client when it is complete. This allows partial utilisation of product and avoids
a long development time. It also creates a large initial capital outlay with the
subsequent long wait avoided. This model of development also helps ease the
traumatic effect of introducing completely new system all at once.
There are some problems with this model. One is that each new build must be
integrated with previous builds and any existing systems. The task of
decomposing product into builds is not trivial either. If there are few builds and
each build degenerates this turns into Build-And-Fix model. However if there are
too many builds then there is little added utility from each build.
C) Iterative Model
Iterative development is at the heart of a cyclic software development process
developed in response to the weaknesses of the waterfall model. It starts with an
initial planning and ends with deployment with the cyclic interactions in between.
Iterative development are essential parts of the Rational Unified Process,
Extreme Programming and generally the various agile software development
frameworks.
It follows a similar process to the Plan-Do-Check-Act of Business process
improvement.
Iterative Development
Iterative Development slices the system functionality into increments (portions).
In each increment, a slice of functionality is delivered through cross-discipline
work, from the requirements to the deployment. The unified process groups
increments/iterations into phases: inception, elaboration, construction, and
transition.
Inception identifies project scope, risks, and requirements (functional and non-
functional) at a high level but in enough detail that work can be estimated.
Elaboration delivers a working architecture that mitigates the top risks and fulfills
the non-functional requirements.
Construction incrementally fills-in the architecture with production-ready code
produced from analysis, design, implementation, and testing of the functional
requirements.
Transition delivers the system into the production operating environment.
Each of the phases may be divided into 1 or more iterations, which are usually
time-boxed rather than feature-boxed. Architects and analysts work one iteration
ahead of developers and testers to keep their work-product backlog full.

5. Describe various types of Object Oriented and Reuse Models.

Object oriented model:
Object-oriented software design is a design strategy where system designers
think in terms of ‘things’ instead of operations or functions. The executing system
is made up of interacting objects that maintain their own local state and provide
operations on that state information (Figure 1). They hide information about the
representation of the state and hence limit access to it. An object-oriented design
process involves designing the object classes and the relationships between
these classes. When the design is realized as an executing program, the
required objects are created dynamically using the class definitions.
Object-oriented analysis and design is more cost-effective and a faster way to
develop software and systems. This technology cuts development time,
overhead and enables software engineers to make reusable, reliable and easily
maintainable applications.

Rational unified process model:

The Rational Unified Process (RUP) is a software process product, originally
developed by Rational Software, which was acquired by IBM in February 2003.
The product includes a hyperlinked knowledge base with sample artifacts and
detailed descriptions for many different types of activities. RUP is included in the
IBM Rational Method Composer (RMC) product which allows customization of
the process.
By 1997, Rational had acquired Verdix, Objectory, Requisite, SQA, Performance
Awareness, and Pure-Atria. Combining the experience base of these companies
led to the articulation of six best practices for modern software engineering:
1. Develop iteratively, with risk as the primary iteration driver
2. Manage requirements
3. Employ a component-based architecture
4. Model software visually
5. Continuously verify quality
6. Control changes
These best practices both drove the development of Rational's products, and
were used by Rational's field teams to help customers improve the quality and
predictability of their software development efforts. To make this knowledge
more accessible, Philippe Kruchten, a Rational techrep, was tasked with the
assembly of an explicit process framework for modern software engineering.
This effort employed the HTML-based process delivery mechanism developed
by Objectory. The resulting "Rational Unified Process" (RUP) completed a
strategic tripod for Rational
Commercial Off-the-shelf model (COTS):
The world of software development has evolved rapidly in the last decade. In
particular, the use of commercial off-the-shelf (COTS) products as elements of
larger systems is becoming increasingly commonplace, due to shrinking
budgets, accelerating rates of COTS enhancement, and expanding system
requirements, according to the Software Engineering Institute (SEI) [13]. The
growing trend toward systems configured of individual components has taken the
original concept of reuse into a completely different arena. It has also presented
many challenges to software developers attempting to enter this new arena.
As this change in practices is taking place, many questions have arisen, such as:
how do we modify standard development practices to fit this new development
paradigm; what methods are now effective; how do we quantify the cost savings
expected of COTS use; and what metrics are worth collecting from COTS
projects?
The term commercial off-the-shelf (COTS) is very generic; it can refer to many
different types and levels of software, e.g., software that provides a specific
functionality or a tool used to generate code. COTS may be one of the most
diversely defined terms in current software development. For the purposes of this
paper, the term COTS means a software product, supplied by a vendor, that has
specific functionality as part of a system—a piece of prebuilt software that is
integrated into the system and must be delivered with the system to provide
operational functionality or to sustain maintenance efforts. For the purposes of
this paper, COTS-based is the term used to indicate component- or package-
based development—rapid configuration of software systems based on COTS
packages, Government off-the-shelf (GOTS) packages, and some custombuilt
reusable packages. The term COTS project refers to a project that integrates
COTS packages and other software to develop a system. This is not to be
confused with the development of COTS packages that occurs at the “vendor”
organization.

The Reengineering model:

The reengineering of software was described by Chikofsky and Cross in their
1990 paper, as "The examination and alteration of a system to reconstitute it in a
new form". Less formally, reengineering is the modification of a software system
that takes place after it has been reverse engineered, generally to add new
functionality, or to correct errors.

6. Describe productivity driven dynamic process modeling.

August 2010
Master of Computer Application (MCA) – Semester 3
MC0071 – Software Engineering– 4 Credits
(Book ID: B0808 & B0809)
Assignment Set – 2 (60 Marks)

Answer all Questions Each question carries TEN marks

Book ID: B0808

1. Explain the following with respect to Configuration Management:
A) Software Reengineering
B) Software Refactoring

2. Describe the various testing strategies in Software Engineering.

3. Explain the following with respect to Software Configuration Management:

A) Change Management B) Version and Release Management

Book ID: B0809

4. Describe the theory of redefining the software engineering process.
5. Describe the concept of Software technology as a limited business tool.

6. Describe the theory of Diversification of Problem-Solving Strategies in Software

Engineering.