SE Questions (Query)
|In unit testing of a module, it is found that for a set of test data, at the maximum 90% of the code alone were tested with the probability of success 0.9. The reliability of the module is||1. Greater than 0.9, 2. Equal to 0.9, 3. At most 0.81, 4. At least 0.81||3. At most 0.81||Given data
Step-1: 90% of code were tested,
Testing with the probability=0.9
Step-2: We can write tested data into 0.9 because it is given in percentages.
Step-3: Reliability of the module = Tested data * probability
= 0.9 * 0.9
= 0.81(at most)
|In a particular program, it is found that 1% of the code accounts for 50% of the execution time. To code a program in C++, it takes 100 man-days. Coding in assembly language is 10 times harder than coding in C++ but runs 5 times faster. Converting an existing C++ program into an assembly language program is 4 times faster.
To completely write the program in C++ and rewrite the 1% code in assembly language, if a project team needs 13 days, the team consists
|1. 13 programmers, 2. 10 programmers, 3. 8 programmers, 4. 100/13 programmers||3. 8 programmers||Software-Engineering||Software-Reliability||https://youtu.be/7iSBpW7K6eE|
|Which of the following is not a UML DIAGRAM?||1. Use Case, 2. Class Diagram, 3. Analysis Diagram, 4. Swimlane Diagram||3. Analysis Diagram||Use Case, Class Diagram and Swimlane Diagram are all three UML diagrams but Analysis Diagram is not.||Software-Engineering||UML|
|To execute all loops at their boundaries and within their operational bounds is an example of||1. Black Box Testing, 2. Alpha Testing, 3. Recovery Testing, 4. White Box Testing||4. White Box Testing||White box testing is a testing technique which evaluates the code and the internal structure of a program. It involves looking at the structure of the code, when a tester already know the internal structure of a product, tests can be conducted to ensure that the internal operations performed according to the specification and all internal components have been adequately exercised.
White Box Testing is coverage of the specification in the code:
1. Code coverage
2. Segment coverage: Ensure that each code statement is executed once.
3. Branch Coverage or Node Testing: Coverage of each code branch in from all possible was.
4. Compound Condition Coverage: For multiple conditions test each condition with multiple paths and combination of the different path to reach that condition.
5. Basis Path Testing: Each independent path in the code is taken for testing.
6. Data Flow Testing (DFT): It is defining the set of intermediate paths through the code.
7. Path Testing: Path testing is where all possible paths through the code are defined and covered.
8. Loop Testing: these strategies relate to testing single loops, concatenated loops, and nested loops.
|Which of the following is not an approach to Software Process Assessment?||1. SPICE(ISO/IEC15504), 2. Standard CMMI Assessment Method for process improvement, 3. ISO 9001:2000, 4. IEEE 2000:2001||4. IEEE 2000:2001||The process assessment leads to process capability determination and process improvement. Process capability determination is an organized assessment, which analyzes the software processes in an organization.The process improvement identifies the changes to be made in the software processes.
Different approaches are used for assessing software process. These approaches are SPICE (ISO/IEC15504), ISO 9001:2000, standard CMMI assessment method for process improvement, CMM-based appraisal for internal process improvement, and Bootstrap.
|A physical DFD specifies||1. what processes will be used, 2. who generates data and who processes it, 3. what each person in an organization does, 4. which data will be generated||2. who generates data and who processes it||Physical DFD specifies actual flow of physical documentation and depicts how the system will be implemented.
The processes represent the programs, program modules, and manual procedures.
The data stores represent the physical files and databases, manual files.
It show controls for validating input data, for obtaining a record, for ensuring successful completion of a process, and for system security.
|In UML diagram of a class||1. state of object cannot be represented, 2. state is irrelevant, 3. state is represented as an attribute, 4. state is represented as a result of an operation||3. state is represented as an attribute||The Unified Modeling Language (UML) is a general-purpose, developmental, modeling language in the field of software engineering, that is intended to provide a standard way to visualize the design of a system.
A class diagram in the Unified Modeling Language (UML) is a type of static structure diagram that describes the structure of a system by showing the system’s classes as attributes, operations and the relationships among objects.
|Which of the following models used for software reliability||1. Waterfall, 2. Musa, 3. COCOMO, 4. Rayleigh||4. Rayleigh||Rayleigh Model:
This model predicts fault detection over the life of the software development effort and can be used in conjunction with the other prediction techniques. Software management may use this profile to gauge the defect status. This model assumes that over the life of the project that the faults detected per month will resemble a Raleigh curve
This prediction technique is used to predict, prior to system testing, what the failure rate will be at the start of system testing. This prediction can then later be used in the reliability growth modelling. For this prediction method, it is assumed that the only thing known about the hypothetical program is a prediction of its size and the processor speed.
The constructive cost model was developed as a model for estimating effort, cost, and schedule for software projects.
Waterfall is the software development life cycle model which depicts the phases of conception, initiation, analysis, design, construction, testing, deployment and maintenance.
Musa model is also used for software reliability testing but Rayleigh model is very popularly used with higher accuracy.
|The Functions Point (FP) metric is||1. Calculated from user requirement, 2. Calculated from lines of code, 3. Calculated from software complexity assessment, 4. None of the above||3. Calculated from software complexity assessment||→ The functional user requirements of the software are identified and each one is categorized into one of five types: outputs, inquiries, inputs, internal files, and external interfaces.
→ Once the function is identified and categorized into a type, it is then assessed for complexity and assigned a number of function points.
→ Each of these functional user requirements maps to an end-user business function, such as a data entry for an Input or a user query for an Inquiry.
→ This distinction is important because it tends to make the functions measured in function points map easily into user-oriented requirements, but it also tends to hide internal functions (e.g. algorithms), which also require resources to implement.
|The lower degree of cohesion is kind of||1. Logical Cohesion, 2. Coincidental Cohesion, 3. Procedural Cohesion, 4. Communicational Cohesion||2. Coincidental Cohesion||Cohesion is a measure of the degree to which elements of a module are functional related.