SE-2 MARKS

    

UNIT 1: SOFTWARE PROCESS AND PROJECT MANAGEMENT

PART – A

1.   Define Software Engineering. [Nov – 2013]
                        Software engineering is the systematic approach to develop and maintain a s                   software product in a cost effective and efficient way.

2. What is Software?

Software is nothing but a collection of computer programs that are related documents that are indented to provide desired features, functionalities and better performance.

3.   What are the Generic Framework Activities?
                        • Communication
                        • Planning
                        • Modeling
                        • Construction
                        • Deployment

4.  What are the characteristics of the software?

1. Software is developed or engineered; it is not manufactured in the classical sense.

2. Software does not “wear out”.

3. Although the industry is moving toward component-based construction, most software         continues to be custom built.

5.   What are the various categories of software?

System software, Application software, Engineering/Scientific software, embedded software, Web Applications, Artificial Intelligence software.

6.  Define software process. List its activities. [May -2013]

Software process is defined as the structured set of activities that are required to develop the software system. The activities are

Ø  Specification

Ø  Design and implementation

Ø  Validation

Ø  Evolution

7.  What are the fundamental activities of a software process?

1. Specification,

2. Design and implementation,

3. Validation

4.  Evolution.

8.  What are the umbrella activities of a software process?

Software project tracking and control,  Risk management, Software Quality Assurance, Formal Technical Reviews, Software Configuration Management, Work product preparation and production, Reusability management, Measurement.

9.  Write the disadvantages of classic life cycle model.
            [i] Real projects rarely follow sequential flow. Iteration always occurs and creates
             problem.
            [ii] Difficult for the customer to state all requirements.
            [iii] Working version of the program is not available. So the customer must have                             patience.

10. What are the potential advantages of adhering to the life cycle model of Software?     [Nov -2012]

o   Easy to use.

o   Work well for projects where requirements are very well understood.

o   Cost effectiveness.

11. ‘Software doesn’t wear out’. Justify. [Nov-2013]

            As the time progress, the hardware components start deteriorating – they are subjected to environment maladies such as dust, vibration, temperature etc., and at same point of time they tend to breakdown.

            But software is no susceptible to the environment changes, software does not wear out. The software works exactly the same way even after years it was first developed unless any charges are introduced to it.

            The changes in the software may occur due to the changes in requirements.

12.  What is EVA?

Earned Value Analysis is a technique of performing quantitative analysis of the software project. It provides a common value scale for every task of software project. It acts as a measure for software project progress.

            13.  What is COCOMO model?

Constructive Cost Model is a cost model, which gives the estimate of number of man-months it will take to develop the software product.

            14. Define Risk. [Nov- 2013]

Risks are the possible problems that might endanger the objectives of the project stakeholders. It is the possibility of a negative or undesirable outcome. A risk is something that has not happened yet and it may never happen; it is a potential problem.

            15.  What is meant by risk management?

Risk management is an activity in which risks in the software projects are   identified.

            16. What is meant by software project scheduling?

Software project scheduling is an activity that distributes estimated effort across the planned project duration by allocating the effort to specified software engineering tasks.

            17.  What is meant by software cost estimation?

The software cost estimation is the process of predicting the resources required for software development process.

           

18.   What is the difference between the “Known Risks” and Predictable Risks” ?    

Known Risks :-
That can be uncovered after careful evaluation of the project plan, the business,  and technical environment in which the product is being developed.
• Example: Unrealistic delivery rate
    Predictable Risks: -
                        Extrapolated from past project experience

Example: Staff turnover.

PART B

1.      1 Explain the life cycle model.[Nov/Dec 2014,2013,2010,201]

            -Waterfall model

            - Incremental process model.

            - Evolutionary process model

2.  Explain iterative waterfall and spiral model for software life cycle and various activities in each phase. [Nov/Dec 2014,2013]

 Iterative waterfall model

 Requirement gathering phase in which all requirements are identified. · The design phase is responsible for creating architectural view of the software.  The implementation phase in which the software design is transformed into coding. · Testing is a kind of phase in which the developed software component is fully tested.  Maintenance is an activity by which the software product can be maintained.

Requirements

Design

Implementation

Testing

Maintenance

SPIRAL MODEL

· The spiral model is divided into number of frame works. These frameworks are denoted by task regions. · Usually there are six task regions. In spiral model project entry point axis is defined.

· The task regions are:

Customer communication

Planning

Risk analysis.

Construct and release.

Customer evaluation.

Drawbacks

· It is based on customer communication.

· It demands considerable risk assessment.

  

UNIT 2: REQUIREMENTS ANALAYSIS AND SPECFICATION

PART A

1.  What is requirement engineering?

Requirement engineering is the process of establishing the services that the customer requires from the system and the constraints under which it operates and is

developed.

2.  What are the characteristics of SRS?

i. Correct – The SRS should be made up to date when appropriate requirements are identified.

ii. Unambiguous – When the requirements are correctly understood then only it is possible to write unambiguous software.

iii. Complete – To make SRS complete, it should be specified what a software designer wants to create software.

iv. Consistent – It should be consistent with reference to the functionalities identified.

v. Specific – The requirements should be mentioned specifically.

vi. Traceable – What is the need for mentioned requirement? This should be correctly identified.

            3.  What are the various types of traceability in software engineering?

i. Source traceability – These are basically the links from requirement to stakeholders who propose these requirements.

ii. Requirements traceability – These are links between dependant requirements.

iii. Design traceability – These are links from requirements to design.

           

            4.  What are the Requirements Engineering Process Functions?
                        • Inception
                        • Elicitation
                        • Elaboration
                        • Negotiation
                        • Specification
                        • Validation
                        • Management

            5. Define Functional requirements.

These are statements of services the system should provide, how the system should react to particular inputs, and how the system should behave in particular situations. In some cases, the functional requirements may also explicitly state what the system should not do.

            6. Define Non-functional requirements.

These are constraints on the services or functions offered by the system. They include timing constraints, constraints on the development process, and constraints imposed by standards. Non-functional requirements often apply to the system as a whole, rather than individual system features or services.

            7. Name the metrics for specifying non-functional requirements. [Nov- 2011]

Property	Measure
Speed	Processed transactions / second user / event response time
Size	Mbytes , Number of ROM chips
Ease of use	Training time, Number of help frames
Reliability	Mean time to failure, Probability of unavailability
Robustness	Time to restart after failure, Percentage of events causing failure, Probability of data corruption on failure
Portability	Percentage of target dependent statements, Number of target systems.

            8. “An SRS is traceable. Comment. [Nov- 2012]

There may be chances of having new requirements during development of the software. Traceability is concerned with relationship between requirements their sources and the system design. Thus changes in requirement is manageable is SRS is traceable.

           

            9. Define User Requirements.

User requirements are statements, in a natural language plus diagrams, of what services the system is expected to provide to system users and the constraints under which it must operate.

            10. Define system requirements.

System requirements are more detailed descriptions of the software system’s functions, services, and operational constraints. The system requirements document [sometimes called a functional specification] should define exactly what is to be implemented. It may be part of the contract between the system buyer and the software developers.

           

            11. What is software requirements document?

The software requirements document is an agreed statement of the system requirements. It should be organized so that both system customers and software developers can use it.

           

12. Write the structure of a requirements document.

                        1. Preface

                        2. Introduction

                        3. Glossary

                        4. User requirements definition

                        5. System architecture

                        6. System requirements specification

                        7. System models

                        8. System evolution

                        9. Appendices

                        10. Index

            13. Define feasibility study.

A feasibility study is a short, focused study that should take place early in the Requirements Engineering process. It should answer three key questions: a] does the system contributes to the overall objectives of the organization? b] Can the system be implemented within schedule and budget using current technology? And c] Can the system is integrated with other systems that are used?

If the answer to any of these questions is no, you should probably no to go ahead with the project.

            14. Define Data dictionary. [May-2013].

The data dictionary can be defined as an organized collection of all the data elements of the system with precise and rigorous definitions so that user and system analyst will have a common understanding of inputs, outputs, components of stores and intermediate calculations.

           

            15. Define Petri Nets analysis.

                       

§  First introduced by Carl Adam Petri in 1962.

§  A diagrammatic tool to model concurrency and synchronization in distributed systems.

§  Very similar to State Transition Diagrams.

§  Used as a visual communication aid to model the system behavior.

§  Based on strong mathematical foundation.

16. Distinguish between the terms inception, elicitation and elaboration with reference to requirements.                                                                                                            [Nov – 2012]

            Requirements elicitation which involves asking the customer user, what the objectives of system, what is to be accomplished? How the system [or] product fits into the needs of the business and how the system [or] product is to be used on a day-to-day basis.

            The goal of the inception phase is to establish a business case for the system. We should identify all external entities that will interact with the system and define these interactions.

            The goals of the elaboration phase are to develop an understanding of the problem domain, establish an architectural framework for the system, to develop the project plan and identify key project risks.

17.  What are the elements of Analysis model?

i. Data Dictionary

ii. Entity Relationship Diagram

iii. Data Flow Diagram

iv. State Transition Diagram

v. Control Specification

vi. Process specification

PART B

1. Explain Feasibility Study.[Nov / Dec 2013]

            - Information Assessment

            - Information Collection

            - Report Writing

2. Explain Requirements Elicitation and Analysis.[April/May 2011]

            - Problem of scope

            - Problem of understanding

            - Problem of volatility

            - Problem of potential factors.

3. Discuss about Requirements Validation. [April/May 2011]

            - Validity checks

            - Consistency checks

            - Completeness checks

            - Realism checks

            - Verifiability

4. Explain Requirements Management.[Nov/Dec 2012]

            - Enduring and Volatile requirements

            - Requirements Management Planning

            - Requirements Management

5. Write about Data dictionary.

            - Name of the data item

            - Aliases

            - Description

            - Related data items

            - Range of value

            - Data structure definition

            - Where used / How used

UNIT 3: SOFTWARE DESIGN

PART A

 1.  What are the elements of design model?

i. Data design

ii. Architectural design

iii. Interface design

iv. Component-level design

           

            2. Define design process.

Design process is a sequence of steps carried through which the requirements are

translated into a system or software model.

3. Draw the DFD notations for the following. [Nov – 2011]

            a] External Entity

                         

4.  List the principles of a good design.                               [Nov-2013]

i. The design process should not suffer from “tunnel vision”.

ii. The design should be traceable to the analysis model.

iii. The design should exhibit uniformity and integration.

iv. Design is not coding.

v. The design should not reinvent the wheel.

            5. What is the design quality attributes ‘FURPS’ meant? [Nov-2012]

§  Functionality

§  Usability

§  Reliability

§  Performance

§  Supportability

6.  What is a cohesive module?

A cohesive module performs only “one task” in software procedure with little interaction with other modules. In other words cohesive module performs only one thing.

            7. What are the different types of Cohesion?

i. Coincidentally cohesive –The modules in which the set of tasks are related with each other loosely then such modules are called coincidentally cohesive.

ii. Logically cohesive – A module that performs the tasks that are logically related with each other is called logically cohesive.

iii. Temporal cohesion – The module in which the tasks need to be executed in some specific time span is called temporal cohesive.

iv. Procedural cohesion – When processing elements of a module are related with one another and must be executed in some specific order then such module is called procedural cohesive.

v. Communicational cohesion – When the processing elements of a module share the data then such module is called communicational cohesive.

           

            8. What is coupling?

Coupling is the measure of interconnection among modules in a program structure. It depends on the interface complexity between modules.

            9. What are the various types of coupling?

i. Data coupling – The data coupling is possible by parameter passing or data interaction.

ii. Control coupling – The modules share related control data in control coupling.

iii. Common coupling – The common data or a global data is shared among modules.

iv. Content coupling – Content coupling occurs when one module makes use of data or control information maintained in another module.

            10. What are the common activities in design process?

i. System structuring – The system is subdivided into principle subsystems components and communications between these subsystems are identified.

ii. Control modeling – A model of control relationships between different parts of the system is established.

iii. Modular decomposition – The identified subsystems are decomposed into modules.

           

            11. Develop a CRC model index card for a class “Account’ used in banking application.

                        Class Account

                        Class type Transaction

                        Class Characteristic: Tangible Permanent Sequential Guarded

                        Responsibility                                                  Collaboration

                        Precedes         Account                                   Customer

                        Details             Show

                        Current            Balance

                        Withdraw        Amount

                        Deposit            Amount

            12. What are the Basic Design principles of Class-Based Components?
                        • Open-Closed Principle [OCP]
                        • Liskov Substitution Principle[LSP]
                        • Dependency Inversion Principle[DIP]
                        • Interface Segregation Principle[ISP]
                        • Release Reuse Equivalency Principle[REP]
                        • Common Closure Principle[CCP]
                        • Common Reuse Principle[CRP]

13. What are the important roles of Conventional component within the software Architecture?
        •Control Component: that coordinates invocation of all other problem domain.
        • Problem Domain Component: That implement Complete or Partial function          required by customer
        • Infrastructure Component: That responsible for functions that support processing required in problem domain.

14. What are the Different types of Design Model?

• Process Dimension: Indicate evolution of Design model as design tasks   executed as part of software process
• Abstraction Dimension: Represent level of detail as each element of analysis model is transformed into design equivalent.

             15.  List out the Different elements of Design Model?
                                    Data Design Elements
                                     Architectural Design Elements
                                     Interface Design Elements
                                     Component Level Design Elements
                                     Deployment Level Design Elements

16.  What is the Objective of Architectural Design?
                        Model overall software structure by representing component interfaces, dependencies and

relationships and interactions.

17.  Define the terms in Software Designing: [Nov – 2014]

  [a] Abstraction :
                        1. Highest Level : Solution is stated in broad term using language of    

problem environment
            2. Lower Level : More detailed description of solution is provided

[b] Modularity:
                        Software is divided into separately named and addressable components,

called Modules that are integrated to satisfy problem requirements.

PART B

1.      Explain the modular design with neat diagrams.

-          Cohesion

-          Coupling

2.       List out design heuristics for effective modular design.[Nov/Dec 2014]

-          Modular Decomposability

-          Modular Composability

-          Modular Understandability

-          Modular Continuity

-          Modular Protection

3.      Write short notes on User Interface Design. [May/June 2013]

-          User Interface Design principles.

-          Interface design Models

-          Interface design process

4.  Explain the design principles.[April/May 2011]

· The design process should not suffer from tunnel vision.

· The design should be traceable to the analysis model.

· Design should not reinvent the wheel.

· The design should minimize the intellectual distance between the software and problem as it exists in the real world.

· The design should be structured to degrade gently, even when aberrant data, events or operating conditions are encountered.

· Design is not coding, coding is not design.

· The design should be assessed for quality as it is being created, not after the fact.· The design should be reviewed to minimize conceptual [semantic] errors.

UNIT 4: TESTING AND IMPLEMENTATION

PART A

1.      Define testing

                        Testing is a process of executing a program with the intent of finding of an error.

2.      Why is testing important?

           Reviews and other SQA activities can and do uncover errors, but they are not sufficient. Every time the program is executed, the customer tests it. Therefore, we have to execute the program with the specific intend of finding and removing all errors. Inorder to find the highest possible number of errors, test must be conducted systematically.

3.      What are the steps of testing?

       Software is tested from two different perspectives:

             1. Internal program logic is exercised using “White-box”, test case design techniques.

             2. Software requirements are exercised using “Black-box”, test case design techniques.

4. Mention the attributes of a good test [nov/dec2010]

           The following are the attributes of good test.

                         1. A good test has a high probability of finding error.

                         2. Good test is not redundant.

                         3. A good test should be “best of breed”

                         4. A good test should be neither too simple nor too complex.

                  5. What is Black box testing?[may/june 2013]

Black box testing is a test case design method that focuses on the functional requirements of the Software. This is otherwise called as functional testing.

                   6. What is White-box testing?

White-box testing is the test case design method that uses the control structure of the procedural design to Derive test class. It is otherwise called as structural testing.

                   7. Mention of advantage and disadvantages of White-box Testing?

                               Advantage:

                                    1. Software’s Structure logic can be tested.

                        Disadvantages:

                         1. Doesn’t ensure that user requirements are met.

                          2.Its test may not mimic real-world situations.

             8. Mention the advantage and disadvantage Black-box Testing?

            Advantages:

Simulates actual system usage.

Makes no system structure assumption.

            Disadvantages:

                        Potential of missing logical errors in software.

                         Possibility of redundant testing

            9. Diffrentiate Black box and White-box Testing.

Black-box Testing:     

              1.No knowledge of the internal logic of the system is used to delevope test case.

              2 tend to uncover error that occur in implementing requirements or design specification.

              3. Uses Validation techniques

              4.Examples Include unit testing, integration testing, system testing, acceptance testing.

              5. Apply during later stages of testing

            White-box Testing:

            1. Knowledge of internal logic of the system is used to develop test cases.

            2. tends to uncover errors that occur during coding of the program

            3. Use verification techniques.

            4. Examples include Feasibility reviews, requirements reviews.

            5. Perform early in testing process.

    `       10. Mention some of the black-box testing techniques?

               Graph-based testing methods, Equivalences partitioning, boundary value analysis, comparison testing  Orthogonal array testing 

            11. Mention some of the White-box testing techniques?

                Basis path testing, loop testing, data flow testing and conditional testing.

            12. What is condition testing?

           Condition testing is a test case design method that exercises logical conditions in a program module.This method focuses on testing each condition in the program.

            13. Mention the Advantage of condition testing?

                  a.) Measurement of test coverage of a condition is simple.

                  b.) The test coverage of condition in a program provides guidance for the generation of

Additional test for the program.

            14. What is meant by data flow testing?[may/june 2014]

The data flow testing method select test path of a program according to location of definition and uses of variables in program.

             15. Mention the advantages of condition testing.

a)      Measurement of test coverage of a condition is simple.

b)      The test coverage of conditions in a program provides guidance for the generation of additional tests for the program.

     .

            16. What is boundary value analysis?

Boundary value analysis is a test case design technique that leads to a selection of test cases that exercise bounding values. This technique has been developed for the reason that a greater number of errors tend to occur at the boundaries of the input domain rather than in the center.

             17. When is orthogonal array testing applicable?

Orthogonal array testing can be applied to problems in which the input domain is relatively small but too large to accommodate exhaustive testing. It is particularly useful in finding errors associated with region faults within a software component.

            18. What is verification and validation?[nov/dec 2010]

Verification refers to the set of activities that ensure that software correctly implements a specific function.

Validation refers to the set of activities that ensure that the software that has been build is traceable to customer requirements.

            19. What is unit testing?

Unit testing focuses verification on the smallest unit of software design-the software component or module. Here the important control paths are tested to uncover errors within the boundary of the module. The unit test is white-box oriented, and the step can be conducted in parallel for multiple components.

             20. What is alpha and beta tests?

Alpha test is the test that is conducted at the developer’s site by a customer. Beta test is the test that is conducted at one or more customer sites by the end-user of the software.

PART B

1.      Explain Cyclomatic Complexity and its Calculation with example.

·         The number of tests to test all control statements equals the cyclomatic complexity

·         Cyclomatic complexity equals number of conditions in a program

·         Useful if used with care. Does not imply adequacy of testing.

·         Although all paths are executed, all combinations of paths are not executed.

123 4 6 5 7 while bottom <= top if (elemArray [mid] == key (if (elemArray [mid]< key 8 9 bottom > top

Independent Paths:

1, 2, 3, 8, 9

1, 2, 3, 4, 6, 7, 2

1, 2, 3, 4, 5, 7, 2

1, 2, 3, 4, 6, 7, 2, 8, 9

Test cases should be derived so that all of these paths are executed

A dynamic program analyser may be used to check that paths have been executed.

Level N Level N Level N Level N Level N Level N–1 Level N–1 Level N–1 Testing sequence Test

 Drivers Test drivers23

2. Explain the types of Black Box testing in detail. [Nov/Dec 2014]

EQUIVALENCE PARTITIONING:

Equivalence partitioning is a black-box testing method that divides the input domain of a program into classes of data from which test cases can be derived. An ideal test case single-handedly uncovers a class of errors (e.g., incorrect processing of all character data) that might otherwise require many cases to be executed before the general error is observed. Equivalence partitioning strives to define a test case that uncovers classes of errors, thereby reducing the total number of test cases that must be developed.

Test case design for equivalence partitioning is based on an evaluation of equivalence classes for an input condition. Using concepts introduced in the preceding section, if a set of objects can be linked by relationships that are symmetric, transitive, and reflexive, an equivalence class is present. An equivalence class represents a set of valid or invalid states for input conditions. Typically, an input condition is a specific numeric value, a range of values, a set of related values, or a Boolean condition.

Equivalence classes may be defined according to the following guidelines:

·         If an input condition specifies a range, one valid and two invalid equivalence classes are defined.

·         If an input condition requires a specific value, one valid and two invalid equivalence classes are defined.

·         If an input condition specifies a member of a set, one valid and one invalid equivalence class are defined.

·         If an input condition is Boolean, one valid and one invalid class are defined. As an example, consider data maintained as part of an automated banking application.

The user can access the bank using a personal computer, provide a six-digit password, and follow with a series of typed commands that trigger various banking functions. During the log-on sequence, the software supplied for the banking application accepts data in the form area code—blank or three-digit number

·         Prefix — three-digit number not beginning with 0 or 1

·         Suffix — four-digit number

·         Password — six digit alphanumeric string

·         Commands — check, deposit, bill pay, and the like

The input conditions associated with each data element for the banking application can be specified as area code: Input condition, Boolean — the area code may or may not be present.

Input Condition, range — values defined between 200 and 999, with specific exceptions.

Prefix: Input condition, range — specified value >200

Input condition, value — four-digit length

Password: Input Condition, Boolean — a password may or may not be present

Input Condition, value — six-character string

Command: Input Condition, set — containing commands noted previously.

Applying the guidelines for the derivation of equivalence classes, test cases for each input domain data item can be developed and executed. Test cases are selected so that the largest numbers of attributes of an equivalence class are exercised at once.

BOUNDARY VALUE ANALYSIS:

For reasons that are not completely clear, a greater number of errors tends to occur at the boundaries of the input domain rather than in the "center." It is for this reason that Boundary Value Analysis (BVA) has been developed as a testing technique. Boundary value analysis leads to a selection of test cases that exercise bounding values. Boundary value analysis is a test case design technique that complements equivalence partitioning. Rather than selecting any element of an equivalence class, BVA leads to the selection of test cases at the "edges" of the class. Rather than focusing solely on input conditions, BVA derives test cases from the output domain as well

Guidelines for BVA are similar in many respects to those provided for Equivalence

Partitioning:

 If an input condition specifies a range bounded by values a and b, test cases should be designed with values a and b and just above and just below a and b.

 If an input condition specifies a number of values, test cases should be developed that exercise the minimum and maximum numbers. Values just above and below minimum and maximum are also tested.

 Apply guidelines 1 and 2 to output conditions. For example, assume that temperature vs. pressure table is required as output from an engineering analysis program. Test cases should be designed to create an output report that produces the maximum (and minimum) allowable number of table entries.

 If internal program data structures have prescribed boundaries (e.g., an array has a defined limit of 100 entries), be certain to design a test case to exercise the data structure at its boundary. Most software engineers intuitively perform BVA to some degree. By applying these guidelines, boundary testing will be more complete, thereby having a higher likelihood for error detection.

3. Explain Unit testing and Structural Testing in detail. [may/june 2011]

UNIT TESTING:

In unit testing the individual components are tested independently to ensure their quantity. The focus is to uncover the errors in design and implementation.

The various tests that are conducted during the unit test are described as below.

·         Module interfaces are tested for proper information flow in and out of the program.

·         Local data are examined to ensure that integrity is maintained.

·         Boundary conditions are tested to ensure that the module operates properly at boundary established to limit or restrict processing.

·         All the basis (independent) paths are tested for ensuring that all statements in the module have been executed only once.

·         All error handling paths should be tested.

a. Drivers and Stub software need to be developed to test incomplete software. The driver is a program that accepts the test data and prints the relevant results and the stub is a subprogram that uses the module interfaces and performs the minimal data if required. This is given by following figure.

b. The unit testing is simplified when a component with high cohesion(with one function) is designed.in such a design the number of test cases are less and one can easily predict or uncover errors.

STRUCTURAL TESTING:

White-box testing, sometimes called glass-box testing is a test case design method that uses the control structure of the procedural design to derive test cases. Using white-box testing methods, the software engineer can derive test cases that (1) guarantee that all independent paths within a module have been exercised at least once,(2) exercise all logical decisions on their true and false sides, (3) execute all loops at their boundaries and within their operational bounds, and (4) exercise internal data structures to ensure their validity.

A reasonable question might be posed at this juncture: "Why spend time and energy worrying about (and testing) logical minutiae when we might better expend effort ensuring that program requirements have been met?" Stated another way, why don’t we spend all of our energy on black-box tests? The answer lies in the nature of software defects

Logic errors and incorrect assumptions are inversely proportional to the probability that a program path will be executed. Errors tend to creep into our work when we design and implement function, conditions, or controls that are out of the mainstream. Everyday processing tends to be well understood, while "special case" processing tends to fall into the cracks.

We often believe that a logical path is not likely to be executed when, in fact, it may be executed on a regular basis. The logical flow of a program is sometimes counterintuitive, meaning that our unconscious assumptions about flow of control and data may lead us to make design errors that are uncovered only once path testing commences.

Typographical errors are random. When a program is translated into programming language source code, it is likely that some typing errors will occur. Many will be uncovered by syntax and type checking mechanisms, but others may go undetected until testing begins. It is as likely that a typo will exist on an obscure logical path as on a mainstream path.

Basis Path Testing:

Basis path testing is a white-box testing technique first proposed by Tom McCabe. The basis path method enables the test case designer to derive a logical complexity measure of a procedural design and use this measure as a guide for defining a basis set of execution paths. Test cases derived to exercise the basis set re guaranteed to execute every statement in the program at least one time during testing.

Flow Graph Notation:

Before the basis path method can be introduced, a simple notation for the representation of control flow, called a flow graph (or program graph) must be introduced. The flow graph depicts logical control flow using the notation illustrated in Figure. Each structured construct has a corresponding flow graph symbol.

To illustrate the use of a flow graph, we consider the procedural design representation in Figure. Here, a flowchart is used to depict program control structure

Figure maps the flowchart into a corresponding flow graph (assuming that no compound conditions are contained in the decision diamonds of the flowchart). Referring to Figure, each circle, called a flow graph node, represents one or more procedural statements. A sequence of process boxes and a decision diamond can map into a single node. The arrows on the flow graph, called edges or links, represent flow of control and are analogous to flowchart arrows. An edge must terminate at a node, even if the node does not represent any procedural statements (e.g., see the symbol for the if-then-else construct). Areas bounded by edges and nodes are called regions. When counting regions, we include the area outside the graph as a region. When compound conditions are encountered in a procedural design, the generation of a flow graph becomes slightly more complicated. A compound condition occurs when one or more Boolean operators (logical OR, AND, NAND, NOR) is present in a conditional statement. Referring to Figure, the PDL segment translates into the flow graph shown. Note that a separate node is created for each of the conditions a and b in the statement IF a OR b. Each node that contains a condition is called a predicate node and is characterized by two or more edges emanating from it.

4. Explain the Regression Testing and Integration Testing in detail.[May/June  2010]

REGRESSION TESTING:

Regression testing is testing done to check that a system update does not re-introduce errors that have been corrected earlier.

All – or almost all – regression tests aim at checking the,

·         Functionality – black box tests.

·         Architecture – grey box tests

Since they are supposed to test all functionality and all previously done changes, regression tests are usually large.

Thus, regression testing needs automatic,

Execution – no human intervention

Checking. Leaving the checking to developers will not work.

We face the same challenge when doing automating regression test as we face when doing automatic test checking in general:

Which parts of the output should be checked against the oracle?

This question gets more important as we need to have more version of the same test due to system variability.

Simple but annoying – and sometimes expensive – problems are e.g.

Use of date in the test output

Changes in number of blanks or line shifts

Other format changes

Changes in lead texts

Simple but annoying – and sometimes expensive – problems are e.g.

Use of date in the test output

Changes in number of blanks or line shifts

Other format changes

Changes in lead texts

Regression testing is a critical part of testing, but is often overlooked. Whenever a defect gets fixed, a new feature gets added, code gets re-factored or changed in any way, and there is always a chance that the changes may break something, that was previously working. Regression testing is the testing of features, functions, etc. that have been tested before, to make sure they still work, after a change has been made to software.

 Within a set of release cycles, the flow is typically as follows: The testers will test the software and find several defects. The developers will fix the defects, possibly add a few more features and give it back to be tested. The testers will then have not only tested the new features, but test all of the old features to make sure they still work.

 Questions often arise as to how much Regression Testing needs to be done. Ideally, in Regression Testing, everything would be tested just as thoroughly as it was the first time, but this becomes impractical as time goes on and more and more features and, therefore, test cases get added. When looking at which tests to execute during regression testing, some compromises need to be made. When deciding, you will want to focus on what has changed. If a feature has been significantly added to or changed, then you will want to execute a lot of tests against this feature. If a defect has been fixed in a particular area you will want to check that area to see that the fix didn't cause new defects. If, on the other hand, a feature has been working well for some time and hasn't been modified only a quick test may need to be executed.

INTEGRATION TESTING:

Integration Testing,

 Tests complete systems or subsystems composed of integrated components

 Integration testing should be black-box testing with tests derived from the specification

             Main difficulty is localising errors

 \

Approaches to Integration Testing:

 Top-down Testing:

Start with high-level system and integrate from the top-down replacing individual components by stubs where appropriate.

Level 2 Level 2 Level 2 Level 2 Level 1 Level 1 Testing sequence Level 2 stubs Level 3 stubs . . .

 Bottom-up Testing:

Integrate individual components in levels until the complete system is created. Level N Level N Level N Level N Level N Level N–1 Level N–1 Level N–1 Testing sequence Test drivers Test drivers

In practice, most integration involves a combination of these strategies

UNIT 5: SOFTWARE PROJECT MANAGEMENT

PART A

1.      What is software project management?

            Software project management is an umbrella activity within software engineering. It begins before any technical activity is initiated and continues throughout the definition, development and support of computer software.

2.      Mention the players in the software project.

            The software process is populated by players who are categorized into one of five constituencies:

a)      Senior managers

b)      Project managers

c)      Practitioners

d)      Customers

e)      End-users

3.      Mention the activities encompassed by project management.

            The project management activity encompasses measurements and metrics, estimation, risk analysis, schedules, tracking and control

.4. Why is measurement necessary for software engineering?

            Measurement can be applied for a software process with the intent of improving it on a continuous basis. It can be used thought a software project to assist in estimation, quality control, productivity assessment and project control. It can be used to assess the quality of technical work products and assist in tactical decision-making as a project proceeds.

4.      Define metric.

            IEEE93define metrics as “ a quantitative measure of the degree to which a system, component or process possesses a given attributes.

5.      Define measure and measurement.

            Measure provides a quantitative indication of the extent, amount, dimension, capacity or size of some attribute of a product or process. Measurement is the act of determining a measure.

6.      What are the different types of measures? Give examples.

            There are two types of measures: Direct and Indirect measures. Direct measures of the product include line of code (LOC) produced, execution speed, memory size and defect reported over some period of time. Indirect measures of the product include functionality, quality, complexity, efficiency, reliability, maintainability etc.

7.  Mention the two categories of metrics.

The two categories of metrics are Size-oriented metrics and funcation-oriended metrics.

8.  What is Function-oriented metrics?

            Function-oriented metrics use a measure of the functionality delivered by application as a normalization value.

9. What is function point? How is it derived?

            Function Point is a function-oriented metric that is derived using an empirical relationship based on countable (direct) measures of software’s information domain and assessments of software complexity.

10. What is the formula for Function Point?

            To compute Function point (FP), the following relationship is used.

            FP=count total X [0.65 +0.01x? If]

            Where count total is the sum of all FP entries

                I_f are “complexity adjustment values”

11. Define cyclomatic complexity.[may/june 2011]

            Cyclomatic complexity is a software metric that provides a quantitative measure of the logical complexity of a program.

12. What is COCOMO model?[may/june 2013]

            COCOMO, Constructive Cost Model is a hierarchy of estimation models that addresses the following areas:

a)      Application composition Model

b)      Early design stage model

c)      Post-architecture-stage model

COCOMO model uses different sizing option like object points, Function points and Lines of source code.

13.  What is Software project scheduling?

            Software project scheduling is an activity that distributes estimated effort across the planned project duration by allocating the effort to specific software engineering tasks.

14.  What is Earned value Analysis?

            Earned Value Analysis is a technique for performing quantitative analysis of progress of the software project. The earned value system provides a common value scale for every task, regardless of the type of work being performed. Earned value is simply a measure of progress.

15. What is Error tracking?

            Error tracking is an activity that provides a means for assessing the status of a current project.

16. What is done during software maintenance?

            Changes are made in response to changed requirements but the fundamental software structure is stable. Modifying a program after it has been put into use, Maintenance does not normally involve major changes to the system architecture. Changes are implemented by modifying existing components and adding new components to the system.

17. What is adaptive maintenance?

            Adaptive maintenance is the maintenance to adapt software to a different operation environment. It involves changing a system so that it operates in a different environment from its initial implementation.

18. What is preventive maintenance?

            Preventive maintenance is the maintenance to enable the software to server the needs of its end users. It involves changing the computer programs so that they can be more easily corrected, adapted and enhanced.

19. What are CASE tools?

            Computer-Aided software Engineering (CASE) tools assist software engineering managers and practitioners in every activity associated with the software process. They automate project management activities, manage all work products produced throughout the process and assist the engineers in their analysis, desing, coding and test work.

PART B

1.      Explain Software Cost Estimation in detail? [Nov/Dec 2010, May/June 2014]

            Software productivity

            Estimation techniques

Algorithmic cost modelling

Project duration and staffing

Fundamental estimation questions are,

SOFTWARE COST COMPONENTS

Hardware and software costs.

Travel and training costs.

Effort costs (the dominant factor in most projects)

The salaries of engineers involved in the project;

Social and insurance costs.

Effort costs must take overheads into account

Costs of building, heating, lighting.

Costs of networking and communications.

Costs of shared facilities (e.g library, staff restaurant, etc.).

COSTING AND PRICING:

Estimates are made to discover the cost, to the developer, of producing a software system.

There is not a simple relationship between the development cost and the price charged to the customer.

 Broader organisational, economic, political and business considerations influence the price charged.

SOFTWARE PRODUCTIVITY:

A measure of the rate at which individual engineers involved in software development produce software and associated documentation.

Not quality-oriented although quality assurance is a factor in productivity assessment.

Essentially, we want to measure useful functionality produced per time unit.

PRODUCTIVITY MEASURES:  

Size related measures based on some output from the software process. This may be lines of delivered source code, object code instructions, etc.

Function-related measures based on an estimate of the functionality of the delivered software. Function-points are the best known of this type of measure.

Lines of code

Estimation techniques

Project duration and staffing

Staffing requirements

2. Explain Software Configuration Management in detail?[may/june 2014]

a) Configuration Management Planning

b) Change Managementc Version and Release Management

d) System Building

e) CASE tools for Configuration Management

CONFIGURATION MANAGEMENT PLANNING:

All products of the software process may have to be managed:

a. Specifications;

b. Designs;

c. Programs;

d. Test data;

e. User manuals.

3. Explain COCOMO Model in detail? [Nov/Dec 2011, 2014]

COCOMO MODELS:

COCOMO has three different models that reflect the complexity:

The Basic Model

The Intermediate Model

The Detailed Model

The Development Modes: Project Characteristics:

Organic Mode:

Relatively small, simple software projects

Small teams with good application experience work to a set of less than rigid requirements

Similar to the previously developed projects

relatively small and requires little innovation

Semidetached Mode:

Intermediate (in size and complexity) software projects in which teams with mixed experience levels must meet a mix of rigid and less than rigid requirements.

Embedded Mode:

Software projects that must be developed within a set of tight hardware, software, and operational constraints

BASIC COCOMO MODEL:

Formula:

E=ab (KLOC or KDSI) bb

D=cb (E) db

P=E/D

*-*-*-*