Q1.Software Maintenance is costlier” Justify the statement

Answer:

Reports suggest that the cost of maintenance is high. A study on estimating software maintenance found that the cost of maintenance is as high as 67% of the cost of entire software process cycle.

On an average, the cost of software maintenance is more than 50% of all SDLC phases. There are various factors, which trigger maintenance cost go high, such as:

Real-world factors affecting Maintenance Cost

• The standard age of any software is considered up to 10 to 15 years.
• Older softwares, which were meant to work on slow machines with less memory and storage capacity cannot keep themselves challenging against newly coming enhanced softwares on modern hardware.
• As technology advances, it becomes costly to maintain old software.
• Most maintenance engineers are newbie and use trial and error method to rectify problem.
• Often, changes made can easily hurt the original structure of the software, making it hard for any subsequent changes.
• Changes are often left undocumented which may cause more conflicts in future.

Software-end factors affecting Maintenance Cost

• Structure of Software Program
• Programming Language
• Dependence on external environment
• Staff reliability and availability

Q2.Give some design principles for maintainability.

Answer:

Design Principles in Software Engineering:

These principles relate to how you develop the design for a system, how you implement specific components, and how you should write your code.

1. Divide and Conquer

One of the core principles in any problem-solving situation, including system design, is divide and conquer. It means breaking a problem into smaller bite-sized subproblems. The idea behind this is that those problems are hard to solve due to their complexity. To make it easier, you can divide these problems into smaller problems. Solving those smaller bits will make it easier to solve the larger problem in the long run.

2. Increase Cohesion

Cohesion means grouping things that make sense together — sort of as one package. From a development point of view, you can choose to design your packages, modules, or classes cohesively.Cohesion brings about the organization of your code, and it will make it much easier to find things, thus simplifying the system.

3. Design for Flexibility

Designing for flexibility comes down to anticipating changes to your system in the future. Your system may be simple in the present but get more complex in the future. You may want to add a lot more stuff. You may want to swap out an implementation of an object or an item for a better one. A lot of times, people design systems for today’s use. They don’t think about the fact that in a month or maybe in a year, they’re going to scale the project up.

4. Design for Portability

When designing a system, you need to remember that it may be used on a different platform or device than what you’re currently targeting. If you are making a web application just for the web, it will be costly and time-consuming if you ever want to turn this into an iOS app, an Android app, a Windows desktop application, or something like that. That may involve creating an entirely new system to be able to port.

Q3.Write a short note on the following:

Answer:

a) Black Box Testing: Black Box Testing is a software testing method in which the functionalities of software applications are tested without having knowledge of internal code structure, implementation details and internal paths. Black Box Testing mainly focuses on input and output of software applications and it is entirely based on software requirements and specifications. It is also known as Behavioral Testing.

There are the generic steps followed to carry out any type of Black Box Testing.

• initially, the requirements and specifications of the system are examined.
• The tester chooses valid inputs (positive test scenario) to check whether SUT processes them correctly. Also, some invalid inputs (negative test scenario) are chosen to verify that the SUT is able to detect them.
• The tester determines expected outputs for all those inputs.
• The software tester constructs test cases with the selected inputs.
• The test cases are executed.
• The software tester compares the actual outputs with the expected outputs.
• Defects if any are fixed and re-tested.

b) White Box Testing:

White Box Testing is software testing technique in which internal structure, design and coding of software are tested to verify flow of input-output and to improve design, usability and security. In white box testing, code is visible to testers so it is also called Clear box testing, Open box testing, Transparent box testing, Code-based testing and Glass box testing.

It is one of two parts of the Box Testing approach to software testing. Its counterpart, Blackbox testing, involves testing from an external or end-user type perspective. On the other hand, Whitebox testing is based on the inner workings of an application and revolves around internal testing.

Working process of white box testing:

Input: Requirements, Functional specifications, design documents, source code.

Processing: Performing risk analysis for guiding through the entire process.

Proper test planning: Designing test cases so as to cover entire code. Execute rinse-repeat until error-free software is reached. Also, the results are communicated.

Output: Preparing final report of the entire testing process.

Testing techniques:

Statement coverage: In this technique, the aim is to traverse all statement at least once. Hence, each line of code is tested. In case of a flowchart, every node must be traversed at least once. Since all lines of code are covered, helps in pointing out faulty code.

Branch Coverge: In this technique, test cases are designed so that each branch from all decision points are traversed at least once. In a flowchart, all edges must be traversed at least once.