Software engineering Questions and Answers

Software engineering Questions and Answers

• 1.
  1. What ismeant by Risk? The problem that could cause some loss or threaten the success of the project, but which has not happened yet. The potential problems might have an adverse impact on cost, schedule, or technical success of the project, the quality of our software products, or project morale. Risk management is the process of identifying addressing and eliminating these problems before they can damage the project. 2. Brief HIPO diagram HIPO diagram were developed at IBM as design representation schemes Top down software development and as external documentation aids for released products. HIPO diagram contains a  visual table of contents  a set of overview diagrams, and  a set of detail diagrams. o The visual table of contents is a directory to the set of diagrams in the package. It consists of tree-structured directory, a summary of the contents of each overview diagram, and a legend 3. Brief s/w maintenance S/W maintenance is the very broad activity that includes error corrections, enhancements of capabilities, deletion of obsolete capabilities, and optimization. Change is inevitable, mechanisms must be developed for evaluating, controlling and making modifications. So any work done to change the software after it is in operation is considered to be maintenance. The purpose is to preserve the value of the s/w overtime. The value can be enhanced by expanding the customer base, meeting additional requirements, becoming easier to use, more efficient and employing newer technology. Maintenance may span for 50 years, whereas development may be 1-2 years. 4. What are all the solutions to Maintenance Problems A number of possible solutions to maintenance problems have been suggested. They include: budget & effort reallocation; complete replacement of existing systems; and enhancement of existing systems. Budget & effort Reallocation It is now-a-days suggested that more time and resources should be invested in the development-specification & design of more maintainable systems rather than allocating resources to develop unmentionable or difficult to maintain systems Complete replacement of the system
• 2.
  If maintaining anexisting system costs as much as developing a new one, why not develop a new system from scratch. This point of view is understandable, but in practice it is not simple. The risk and costs associated with complete system replacement are very high. Corrective & preventive maintenance take place periodically at relatively small but incremental costs. Some organization can afford to pay for these comparatively small maintenance charges while at the same time supporting more ambitious and financially demanding project may not be possible. Maintenance of Existing System Complete replacement of the system is not usually a viable option. An operational system in itself can be asset to an organization in terms of the investment in technical knowledge and the working culture engendered. The current system may need to have the potential to evolve to a higher state. 5. Software Reengineering Software reengineering is concerned with taking existing legacy systems and re implementing them to make them more maintainable. As a part of this reengineering process, the system may be redocumented or restructured. It may be translated to a more modern programming language, implemented on existing hardware technology. Software re-engineering allows us to translate source code to a new language, restructure our old code, migrate to a new platform capture and then graphically display design information, and redocument documented systems. New S/W Development System Specification Design & Implementation New System Re-engineering Existing Software System Understanding and Transformation Reengineer ed System
• 3.
  The costs ofre-engineering depend on the extent of the work that is carried out. Other factors affecting costs are the quality of the software. The following suggestions may be useful for the modification of the legacy code: Study code well before attempting changes Concentrate on overall control flow not coding Heavily comment internal code Create Cross references Build Symbol tables Use own variables, constants and declaration to localize the effect of change Keep detailed maintenance document Use modern design techniques 6. Define Modularity Modularity is the way of defining the system as a collection of well defined, manageable units with well defined interfaces among the units. Desirable properties of a modular system include: Each module is a well defined subsystem that is potentially useful in other applications Each module has a single, well defined purpose. Modules can be separately compiled and stored in a library Modules can use other modules. Modules should be easier to use than to build Modules should be simpler from the outside than from the inside. Modularity is the single attribute from the outside than from the inside be intellectually manageable. It enhances the design clarity , which in turn eases implementations, debugging, documenting and maintenance of the s/w product. 7. What do you mean by Abstraction? Abstraction is the intellectual tool that allows us to deal with concepts apart from particular instances of those concepts. During requirements definition an design, abstraction permits separation of the conceptual aspects of a system from the implementation details. We can specify the FIFO property of a queue or the LIFO property of a stack without concern for the representation scheme to be used in implementing the stack or queue. Three widely used abstraction mechanism in s/w design are  functional abstraction
• 4.
    data abstraction control abstraction. FunctionalAbstraction It involves the use of parameterized subprograms. The ability to parameterize a subprogram and to bind different parameter values on different invocations of the subprogram is a powerful abstraction mechanism. Data Abstraction It involves specifying a data type or a data object by specifying legal operations on objects. Represention and manipulation details are suppressed. Abstract data type is used to denote decleration of data type from which numerous instances can be created. Abstract data types are abstract in the sense that representation details of the data items and implementation details of the functions that manipulate the data items are hidden within the group that implements the abstract type. Control Abstraction It is the third commonly used abstraction mechanism in software design. Control abstraction is used to state a desired effect without stating the exact mechanism of control. IF statements and WHILE statements in modern programming languages are abstractions of machine code implementations that involve conditional jump instructions. A statement of the form “for all I in S sort files I” leaves unspecified the sorting techniques, the nature of S, the nature of the files, and how “for all I in S” is to be handled. 8. What is the Modularization Criteria? 1. 2. 3. 4. 5. A s/w module to be a named entity has the following characteristics: Modules contain instruction, processing logic, and data structures Modules can be separately compiled and stored in a library Modules can be included in a program Module segments can be used by invoking a name and some parameters. Modules can use other modules. Modularization allows the designer to decompose a system into functional units to impose hierarchical ordering on functional usage, to implement data abstractions, and to develop independently useful subsystems.
• 5.
  9. Define Couplingand Cohesion Coupling is the measure of the degree of interdependence between modules. Two modules with high coupling are strongly interconnected and thus, dependent on each other. Two modules with low coupling are not dependent on one another. The strength of coupling between two modules is influenced by the complexity of the interface, the type of connection, and the type of communication . Modification of a common data block or control block may require modification of all routines that coupled to that block. If modules communicate only parameters, and if the interfaces between modules remain fixed, the internal details of modules can be modified without having to modify the routines that use the modified modules. Coupling between modules can be ranked on a scale of strongest to weakest as follows: 1. Content coupling 2. Common coupling 3. Control coupling 4. Stamp coupling 5. Data coupling 10. Define Cohesion? Cohesion is the measure of the degree to which the elements of a module are functionally related. A strongly cohesive module implements functionality that is related to one feature of the solution and requires little interaction with other modules. The internal cohesion of a module is measured in terms of the strength of binding of elements within the module. Cohesion of elements occurs on the scale of weakest to strongest as follows: 1. Coincidental cohesion 2. Logical Cohesion 3. Temporal cohesion 4. Communication cohesion 5. sequential cohesion 6. Functional Cohesion 7. Informational cohesion 11. What is meant by specification principles? A number of specification principles adapted from the work of Balzer and Goldman is as follows: 1. Separate functionality from implementation 2. Develop a model of the described behaviour of a system that encompases the data and the functional responses of a system to various stimuli from the environment 3. Establish the context in which software operates by specifying the manner in which other system components interact with software.
• 6.
  4. Define theenvironment in which the system operates and indicates how “a highly intertwined collection of agents react to stimuli in the environment produced by those agents. 5. Create a cognitive model rather than a design or implementation model. The cognitive model describes a system as perceived by its user community. 12. Give the importance of Risk analysis Risk always involves two characteristics: Uncertainity- The event that characterizes the risk may or may not happen; i.e. there are no 100% probable risk Loss: If the risk becomes a reality, unwanted consequences or losses will occur. It is important to quantify the level of uncertainty and the degree of loss associated with the each risk. Different categories of risks are considered. Different categories of risks are considered. Project risk : If project risk become real, it is likely that the project schedule will slip and that cost will increase. Technical risks: It threaten the quality and timeliness of the s/w to be produced. If a technical risk becomes a reality, implementation may become difficult or impossible. Business risks: It threatens the viability of the s/w to be built. Known risks: The risks are uncovered after careful evaluation of the project plan, the business and technical environment in which the project is being developed. 13. Define s/w Reliability S/W reliability is defined in statistical term as “The probability of failure free operation of a computer program in a specified environment for a specified time” Eg. Program X is estimated to have a reliability of 0.96 over eight elapsed processing hours. i.e. if a program X were to be executed 100 times and require eight hours of elapsed processing time, it is likely to operate correctly 96 times out of 100. According to s/w quality and realiability failure is nonconformance to s/w requirements. For a computer based system a simple measure of reliability is mean time between failure (MTBF) where MTBF = MTTF + MTTR MTTF - mean time to failure MTTR – mean time to repair 14. Explain the various classifications of s/w metrics Project Metrics Size oriented metrics
• 7.
  S/W metrics arederived by normalizing quality and/or productivity measures by considering the “size “ of the s/w that has been produced . If a s/w organization maintains simple records, a table of size-oriented measures. Function oriented metrics S/w metrics use a measure of the functionality delivered by the application as a normalization value. Functionality can not be measured directly, it must be derived indirectly using other direct measures. Measurement is done by function point. Function points are derived using an empirical relationship based on countable measures of software’s information domain and assessments of software complexity. Extended Function Point metrics The function point metric was originally designed to be applied to business information systems applications. To accommodate these applications, the data dimension was emphasized to the exclusion of the functional and behavioral dimensions. 15. Brief COCOMO model The name COCOMO stands for COnstrutive COst MOdel. It is an hierarchy model. Basic COCOMO Model: It computes software development effort as function of program size expressed in estimated lines of code Italic COCOMO Model: It computes software development effort as a function of program size and a set of cost drivers that include subject assessments of product, hardware, personnel, and project attributes. Advanced COCOMO Model: It incorporates all characteristics of the intermediate version with an assessment of the cost driver’s impact on each step of the s/w engineering process. 16. Give the various s/w testing strategies White box testing It is also called as glass box testing. It is a test case design method that uses the control structure of the procedural design to derive test cases. Basis path testing method The basis path method enables the test case designer to derive a logical complexity measure of a procedural design and use this measure for defining a basis set of execution paths. Control structure Testing
• 8.
  (i) Condition Testing A simplecondition is a Boolean variable or a relational expression, possibly preceded with one NOT operator (ii) Data Flow testing Data flow testing method selects test paths of a program according to the locations of definitions and uses of variables in the program. (iii) Loop testing Black box testing Black box testing focuses on the functional requirements of the s/w. Black box testing enables the s/w engineer to derive sets of input conditions that will fully exercise all functional requirements for a program. 17. What is the need for baseline? Change is a fact of life in s/w development Customers want to modify requirements. Developers want to modify technical approach. Managers want to modify project approach. A baseline is a software configuration management concept that helps us to control change without seriously impeding justifiable change. After an initial baseline is established and forzen, every subsequent change is recorded as delta until the next baseline is set. It is desirable to establish a baseline at an early point in every project. Establishing a baseline too early, will impose unnecessary procedures and slow the programmers’ work. Baseline Scope For code control, the baseline contains all the project code. The items to be included for the implementation phase are o Current level of each module, including source and object code o Current level of each test case, including source and object code o The current level of any special test or operational data o The current level of all macros, libraries, and files 18. Brief the need of SCM Software configuration management is a set of activities that have been developed to manage change throughout the the life cycle of computer software. SCM can be viewed as a s/w quality assurance activity that is applied throughout the s/w process. The output of the s/w process is information that may be divided into three broad categories (i) Computer programs (ii) Documents that describes the program (iii) Data As the s/w process progresses , the number of software configuration items(SCIs) grows rapidly. A system specification spawns a s/w project plan and s/w requirements specification.
• 9.
  19. List outthe s/w configuration items The following SCIs become the target for configuration management techniques and form a set of baselines. 1. System specification 2. Software project plan 3. Software Requirements Specification (a) Graphical analysis models (b) Process specifications (c) Prototype (d) Mathematical specification 4. Preliminary User Manual 5. Design specification a) Data Design Description b) Architectural design specification c) Module design description d) Interface design descriptions e) Object descriptions 6. Source code listing 7. Test spcification a) Test plan and procedures b) Test cases and recorded results 8. Operation and Installation Manuals 9. Executed Program a) Module executable code b) Linked Modules 10. Database Descriptions a) Schema file structure b) Initial content 11. As-built User manual 12. Maintenance Documents a) Software problem reports b) Maintenance requests c) Engineering change orders 13. Standards and procedures for s/w engineering 20. Write about SCM standards Over the past two decades a number of s/w configuration management standards have been proposed. Many early SCM standards, such as MIL-STD-483, DOS-STD480A, and MIL-STD-1521A, focused on s/w developed for militry applications. More recent ANSI / IEEE standards such as ANSI / IEEE Std. No. 1042-1987, and Std.No. 1028-1988, are applicable for commercial software and recommended for both large and small software engineeringorganizations.
• 10.
  21. What isthe role of SQA The people responsible for the s/w projects are the only ones who can be responsible for quality. The role of SQA is to monitor the way these groups perform their responsibilities. 1. 2. 3. 4. 5. 6. Review all development and quality plans for completeness Participate as inspection moderators in design and code inspections Review all test plans for adherence to standards Review a significant sample of all test results to determine adherence toplans Periodically audit SCM performance to determine adherence to standards Participat in all project quarterly and phase reviews and register ononconcurrence if the appropriate standards and procedures have not been reasonably met. 22. Write about SQA plan              Each development and maintenance project should have Software Quality Assurance Plan (SAQP) that specifies its goals, the SQA tasks to be performed the standards against which the development work is to be measured, and the procedures and organizational structure. The IEEE standard for SQAP preparation contains the following outline Purpose Reference Documents Management Documentation Standards, Practices, and Conventions Reviews and audits Software configuration Management Problem reporting and Corrective Action Tools, techniques, and methodologies Code controls Media control Supplier control Records collection, Maintenance, and Retention The documentation section should describe the documentation to be produced and how it is to be reviewed. 23. Define testing, verification, validation and debugging Testing The process of executing a program with the intention of finding errors Verification An attempt to find erros by executing program in a test or simulated environment Validation
• 11.
  An attempt tofind erros by executing a program in a real environment Debugging Diagnosing the precise nature of a known error and then correcting it. 24. What are all the types of testing 1. Unit or Module test It verifies single programs or modules. These are typically conducted in isolated or special test environments 2. Integration tests It verifies the interfaces between system parts (modules, components, and subsystems) 3. External function tests It verifies the external system functions, as stated in the external specifications 4. Regression tests It runs a subset of previously executed integration and function tests to ensure that program 5. System tests It verifies and/or validate the system to its initial objectives 6. Acceptance tests It validates the system or program to the user’s requirements 7. Installation test It validate the installability and operability of the user’s system 25. What do you mean by Regression testing Regression testing is particularly important in software maintenance,where it is not uncommon for bug fixes to disrupt seemingly unrelated functions. The basic regressing testing approach is to incorporate selected test cases into a regression test bucket that is run periodically in an attemp to detect Regression problems. 26. What are all the element of s/w plan 1. Goals and objectives: It describes what is to be done, for whom, and by when, as well as the criteria for determining project success 2. Work Breakdown structure(WBS) The WBS subdivides the project into tasks that are each defined, estimated and tracked. 3. Product size estimates: These are quantitative assessments fo the code required for each product element. Contingencies are applied to yield reasonable estimates of the resources required fro each WBS element. 4. Project Shedule: Based on the available project staffing and resource estimates, a schedule for the key tasks and deliverable items is produced.