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) Parallel or Concurrent development model B) Hacking

2. Explain the Software Architectural design.

3. Describe the following system models giving appropriate real time examples:
A) Data Flow Models B) Semantic Models C) Object Models

Book ID: B0809

4. Describe the following software life cycle models:
A) Waterfall Model B) Incremental Model C) Iterative Model

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

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
Software re-engineering is concerned with re-implementing legacy systems to make them more
maintainable. Re-engineering may involve re-documenting the system, organizing and restructuring the
system, translating the system to a more modern programming language and modifying and updating
the structure and values of the system’s data. The functionality of the software is not changed and,
normally, the system architecture also remains the same.

There are so many systems in existence that complete replacement or radical restructuring is financially
unthinkable for most organizations. Maintenance of old systems is increasingly expensive so re-
engineering these systems extends their useful lifetime. As discussed in Chapter 26, re-engineering
a system is cost- effective when it has a high business value but is expensive to maintain. Re-
engineering improves the system structure, creates new system documentation and makes it easier to
understand.

Re-engineering a software system has two key advantages over more radical approaches to system
evolution:
1. Reduced risk there is a high risk in re-developing software that is essential for an organization. Errors
may be made in the system specification; there may be development problems, etc.
2. Reduced cost the cost of re-engineering is significantly less than the costs of developing new
software. Ulrich (Ulrich, 1990) quotes an example of a commercial system where the re-implementation
costs were estimated at $50 million. The system was successfully re-engineered for £12 million. If
these figures are typical, it is about 4 times cheaper to re-engineer than to re-write.

Following figure illustrates a possible re-engineering process. The input to the process is a legacy
program and the output is a structured, modularized version of the same program. At the same time as
program re-engineering, the data for the system may also be re-engineered. The activities in this re-
engineering process are:
1. Source code translation The program is converted from an old programming language to a more
modern version of the same language or to a different language.
2. Reverse engineering the program is analyzed and information extracted from it which helps to
document its organization and functionality.
3. Program structure improvement the control structure of the program is analyzed and modified to
make it easier to read and understand.
B) Software Refactoring
Software Recapturing is the process of changing a computer program's source code without modifying
its external functional behavior in order to improve some of the nonfunctional attributes of the software.
Advantages include improved code readability and reduced complexity to improve the maintainability of
the source code, as well as a more expressive internal architecture or object model to improve
extensibility.

Recapturing is usually motivated by noticing a code smell. For example the method at hand may be very
long, or it may be a near duplicate of another nearby method. Once recognized, such problems can be
addressed by recapturing the source code, or transforming it into a new form that behaves the same as
before but that no longer "smells". For a long routine, extract one or more smaller subroutines. Or for
duplicate routines, remove the duplication and utilize one shared function in their place. Failure to
perform recapturing can result in accumulating technical debt.

There are two general categories of benefits to the activity of recapturing.

Maintainability. It is easier to fix bugs because the source code is easy to read and the intent of its
author is easy to grasp. This might be achieved by reducing large monolithic routines into a set of
individually concise, well-named, single-purpose methods. It might be achieved by moving a method to
a more appropriate class, or by removing misleading comments.

Extensibility. It is easier to extend the capabilities of the application if it uses recognizable design
patterns, and it provides some flexibility where none before may have existed
Before refactoring a section of code, a solid set of automatic unit tests is needed. The tests should
demonstrate in a few seconds that the behavior of the module is correct. The process is then an
iterative cycle of making a small program transformation, testing it to ensure correctness, and making
another small transformation. If at any point a test fails, you undo your last small change and try again in
a different way. Through many small steps the program moves from where it was to where you want it to
be. Proponents of extreme programming and other agile methodologies describe this activity as an
integral part of the software development cycle.

Here are some examples of code refactorings:

• Techniques that allow for more abstraction

o Encapsulate Field – force code to access the field with getter and setter methods
o Generalize Type – create more general types to allow for more code sharing
o Replace type-checking code with State/Strategy
o Replace conditional with polymorphism
• Techniques for breaking code apart into more logical pieces
o Extract Method, to turn part of a larger method into a new method. By breaking down
code in smaller pieces, it is more easily understandable. This is also applicable to
functions.
o Extract Class moves part of the code from an existing class into a new class.
• Techniques for improving names and location of code
o Move Method or Move Field – move to a more appropriate Class or source file
 o Rename Method or Rename Field – changing the name into a new one that better
reveals its purpose
o Pull Up – in OOP, move to a superclass
o Push Down – in OOP, move to a subclass

2. Describe the various testing strategies in Software Engineering.

Software testing is an investigation conducted to provide stakeholders with information about the quality
of the product or service under test. Software testing also provides an objective, independent view of the
software to allow the business to appreciate and understand the risks of software implementation. Test
techniques include, but are not limited to, the process of executing a program or application with the
intent of finding software bugs.
Software testing can also be stated as the process of validating and verifying that a software
program/application/product:

o meets the business and technical requirements that guided its design and development;
o works as expected; and
o can be implemented with the same characteristics.

Software testing, depending on the testing method employed, can be implemented at any time in the
development process. However, most of the test effort occurs after the requirements have been defined
and the coding process has been completed. As such, the methodology of the test is governed by the
software development methodology adopted.

Testing methods:

The box approach

Software testing methods are traditionally divided into white- and black-box testing. These two
approaches are used to describe the point of view that a test engineer takes when designing test cases.

White box testing

White box testing is when the tester has access to the internal data structures and algorithms including
the code that implement these.

Types of white box testing

The following types of white box testing exist:

o API testing (application programming interface) - testing of the application using public
and private APIs
o Code coverage - creating tests to satisfy some criteria of code coverage (e.g., the test
designer can create tests to cause all statements in the program to be executed at least
once)
o Fault injection methods - improving the coverage of a test by introducing faults to test
code paths
 o Mutation testing methods
o Static testing - White box testing includes all static testing

Test coverage
White box testing methods can also be used to evaluate the completeness of a test suite that was
created with black box testing methods. This allows the software team to examine parts of a system that
are rarely tested and ensures that the most important function points have been tested.
Two common forms of code coverage are:

• Function coverage, which reports on functions executed

• Statement coverage, which reports on the number of lines
executed to complete the test

They both return a code coverage metric, measured as a percentage.

Black box testing

Black box testing treats the software as a "black box"—without any knowledge of
internal implementation. Black box testing methods include: equivalence partitioning,
boundary value analysis, all-pairs testing, fuzz testing, model-based testing,
traceability matrix, exploratory testing and specification-based testing.

Specification-based testing: Specification-based testing aims to test the functionality

of software according to the applicable requirements. Thus, the tester inputs data into,
and only sees the output from, the test object. This level of testing usually requires
thorough test cases to be provided to the tester, who then can simply verify that for a
given input, the output value (or behavior), either "is" or "is not" the same as the
expected value specified in the test case.
Specification-based testing is necessary, but it is insufficient to guard against certain
risks.
Advantages and disadvantages: The black box tester has no "bonds" with the code,
and a tester's perception is very simple: a code must have bugs. Using the principle,
"Ask and you shall receive," black box testers find bugs where programmers do not.
On the other hand, black box testing has been said to be "like a walk in a dark
labyrinth without a flashlight," because the tester doesn't know how the software being
tested was actually constructed. As a result, there are situations when (1) a tester
writes many test cases to check something that could have been tested by only one
test case, and/or (2) some parts of the back-end are not tested at all. Therefore, black
box testing has the advantage of "an unaffiliated opinion", on the one hand, and the
disadvantage of "blind exploring", on the other.
Grey box testing

Grey box testing (American spelling: gray box testing) involves having knowledge of
internal data structures and algorithms for purposes of designing the test cases, but
testing at the user, or black-box level. Manipulating input data and formatting output do
not qualify as grey box, because the input and output are clearly outside of the "black-
box" that we are calling the system under test. This distinction is particularly important
when conducting integration testing between two modules of code written by two
different developers, where only the interfaces are exposed for test. However,
modifying a data repository does qualify as grey box, as the user would not normally
be able to change the data outside of the system under test. Grey box testing may
also include reverse engineering to determine, for instance, boundary values or error
messages.

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

A) Change Management B) Version and Release Management

A) Change Management

A well functioning Change Management System includes the following functions:

_Managing multiple control levels of configuration management – (Organizational,
Product Line, Project)
_Creation and dissemination of configuration management status reports to projects
_Preserving the contents of the configuration management system
_ backup and restoring of configuration management files
_ recovery from configuration management errors
_ archiving of configuration management files
_ disaster recovery

Change requests apply to not only new or changed requirements, but also system
failures and defects in work products
The change request process typically contains the following steps:
_The change request is recorded
_The impact the change will have on the work product, related work products, and
schedule and cost is determined
_The change request is reviewed and agreement is reached with those affected by the
change request
_The change request is tracked to closure

Change control involves:

_Tracking each configuration item
_Approving a new configuration
_Updating the baseline
_ Check-in, check-out procedures are used to maintain the correctness and integrity of
the CMS
_ Reviews and regression testing are performed to ensure that changes have not
caused unintended effects on the baselines
_ Authorization from the Configuration Control Board must be obtained before
changed configuration items are re-entered into the CMS
_ All changes and the reasons for the changes must be recorded in sufficient detail to
provide change history and

B) Version and Release Management

Version and Release Management is the relatively new but rapidly growing discipline
within software engineering of managing software releases.

As software systems, software development processes, and resources become more

distributed, they invariably become more specialized and complex. Furthermore,
software products (especially web applications) are typically in an ongoing cycle of
development, testing, and release. Add to this an evolution and growing complexity of
the platforms on which these systems run, and it becomes clear there are a lot of
moving pieces that must fit together seamlessly to guarantee the success and long-
term value of a product or project.
The need therefore exists for dedicated resources to oversee the integration and flow
of development, testing, deployment, and support of these systems. Although project
managers have done this in the past, they generally are more concerned with high-
level, "grand design" aspects of a project or application, and so often do not have time
to oversee some of the more technical or day-to-day aspects. Release Managers (aka
"RMs") address this need. They must have a general knowledge of every aspect of the
Software Development Life Cycle (SDLC), various applicable operating systems and
software application or platforms, as well as various business functions and
perspectives.

A Release Manager is:

• Facilitator – serves as a liaison between varying business units to guarantee

smooth and timely delivery of software products or updates.
• Gatekeeper – “holds the keys” to production systems/applications and takes
responsibility for their implementations.
• Architect – helps to identify, create and/or implement processes or products to
efficiently manage the release of code.
• Server Application Support Engineer – help troubleshoot problems with an
application (although not typically at a code level).
• Coordinator – utilized to coordinate disparate source trees, projects, teams and
components.

Some of the challenges facing a Software Release Manager include the management
of:

• Software Defects
• Issues
• Risks
• Software Change Requests
• New Development Requests (additional features and functions)
• Deployment and Packaging
• New Development Tasks

Book ID: B0809

4. Describe the theory of redefining the software engineering process.

The pervasiveness of software in business makes it crucial that software engineers

and developers understand how software development impacts an entire organization.
Strategic Software Engineering: An Interdisciplinary Approach presents software
engineering as a strategic, business-oriented, interdisciplinary endeavor, rather than
simply a technical process, as it has been described in previous publications.

The book addresses technical, scientific, and management aspects of software

development in a way that is accessible to a wide audience. It provides a detailed,
critical review of software development models and processes, followed with a
strategic assessment of how process models evolved over time and how to improve
them. The authors then focus on the relation between problem-solving techniques and
strategies for effectively confronting real-world business problems. They also analyze
the impact of interdisciplinary factors on software development, including the role of
people and business economics. The book concludes with a brief look at specialized
system development.

The diverse backgrounds of the authors, encompassing computer science, information

systems, technology, and business management, help create this book's integrated
approach, which answers the demand for a comprehensive, interdisciplinary outlook
encompassing all facets of how software relates to an organization.

5. Describe the concept of Software technology as a limited business tool.

As e-commerce transforms the way business is conducted -- with companies using the
Internet to enter new markets, shrink supply chains, create value chains and meet the
challenges of increased competition and global markets -- optimization will play a key
role.
E-commerce requires intelligent supply chains, which must provide instant access to
the right data anywhere. Sophisticated Software technology engines can not only
make possible real-time collaborative decision making among all partners in the supply
chain with the web as the medium, but can greatly increase responsiveness to
customers.
This is the emerging world of e-collaboration, which takes supply chain management
to the next level. Companies will move beyond the singular mentality of intra-company
Software technology to focus on how inter-company e-collaboration can transform
consumer demand into consumer satisfaction. For example, a company can do
forecasts collaboratively across its virtual organization, using optimized planning
applications within its manufacturing, distribution and transportation resources to meet
expected demand and actual customers orders. E-collaboration addresses volume
planning, production scheduling, sequencing, distribution management, and
procurement planning.
The Internet is already changing how companies deal with customers via quickly
emerging Customer Relationship Management (CRM) applications such as those that
include product configuration software. The best configurations offer intelligent support
to help customers select online the parts or features they want to include in their
product to meet their specifications.
New uses for Software technology are appearing every day, as more and more
industries adopt the techniques and the technology. What began with airlines and
hotels is now expanding into areas that have never considered Software technology,
such as retailing and financial services. Optimization is helping these industries take
advantage of changing markets and evolving opportunities, giving rise to fresh
challenges and approaches—problems that will lead scientists and engineers to the
next generation of optimization applications.

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

Engineering.

Diversification in software engineering is an important term, in software engineering

the diversification can be understood by dividing the software engineering into two
parts as:
1. Problem level software engineering.
2. Solution level software engineering.

In problem level the diversity is driven due to:

a. Scope and complexity of problems
b. Types of requirements and forms of problems
c. Need to learn and apply new capabilities
d. Challenges of continuous change
e. Impact of the consumer economy and interdisciplinary effects
f. Development of e-business applications
g. Multiplicity of stakeholders, project team skills, background

Requirements and business goals. In solution level the diversity is driven due to:
a. Project management approaches
b. General standards
c. Quality-assurance standards
d. Hardware and software tools
e. Networking tools
f. Data mining and automation tools
g. Nature, scope, and domain of applications
h. Need for business-driven software engineering
i. Secure software engineering
j. “Killer” applications
k. Mobile or wireless software engineering
These are the various factors which are responsible for the diversity in the software
engineering.
Driving Forces of Diversity in Development Strategies
Diversity is a prevalent characteristic of the software process modeling literature. This
reflects the evolution in software development in response to changes in business
requirements, technological capabilities, methodologies,
and developer experience. Process diversity also reflects the changing dimensions of
project requirements, with process models maturing over time in their ability to address
evolving project requirements. Diversification is also driven by the increasing
importance of interdisciplinary views in modeling software processes.
Diversity can be acquired through inheritance as well as by overriding the
presuppositions that derive from inheritance. Cultural differences are examples of
inherited characteristics that affect the degree of diversification in an environment.
Scientific, social, political, psychological, philosophical, experiential, and other
differences modulate acquired diversity through exposure to values, education,
involvement, and interaction.
The culture difference, technology difference etc leads to diversification, but at the
same time such differences or changes will also leads to increase in “RISK”.
Hence it is important to deal with the diversification to improve the market stability,
while at the same time reducing the risk.