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 existedBefore 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 methodso Generalize Type – create more general types to allow for more code sharingo Replace type-checking code with State/Strategyo 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 superclasso 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 APIso 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 methodso Static testing - White box testing includes all static testing

Test coverageWhite 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.