Software Engineering BCA Solved Question Paper Pdf Notes

Discover notes about Software Engineering from BCA solved question papers. Learn the fundamentals of project management and software development, and gain knowledge to master software engineering techniques.

Dudes 🤔.. You want more useful details regarding this subject. Please keep in mind this as well.

Important Questions For Software Engineering:
* Important Short Questions
* Solved Question Paper
* Syllabus

Section A: Software Engineering Very Short Question Answers

Q1. What is feasibility study? What are the contents we should contain in the feasibility report? 

Ans. Feasibility Study: Feasibility is the measure of how beneficial or practical the development of an information system will be to an organisation. 

The technique of determining feasibility is known as feasibility analysis. A feasibility analysis evaluates a system proposal based on its feasibility, influence on the organisation, ability to meet user needs, and effective use of resources. Throughout the life cycle, feasibility should be assessed. 

The results of a feasibility study are often reported in a feasibility report. The degree of detail in such reports would be greatly dependent on the nature of the project, the organisation and the scale of investments. The following are the contents of the report:  

• (a) Introduction 
  • (i) Statement of problem 
  • (ii) Implementation environment
  • (iii) Constraints  
• (b) Management summary and recommendations
  • (i) Important findings 
  • (ii) Comments
  • (iii) Recommendations  
  • (iv) Impact 
• (c) Alternatives
  • (i) Alternative system configurations 
  • (ii) Criteria used in selecting the final approach 
• (d) System description 
  • (i) Abbreviated statement of scope 
  • (ii) Feasibility of all ocated elements  
• (e) Cost benefit analysis 
• (f) Evaluation of technical risk 
• (g) Legal remifications  
• (h) Other project specific topics. 

Q2. Differentiate between verification and validation. 

Ans. Verification and Valídation: Verification is a series of operations that ensures that software performs a specified function correctly. Validation refers to a distinct set of actions that confirm the programme was produced in accordance with customer specifications. 

The role of verification is to ensure that the software adheres to its specifications. You must ensure that the system meets its functional and non-functional requirements. Validation is a broad concept. You must ensure that the software meets the customer’s expectations. However, requirements validation is unlikely to uncover all requirement issues. 

Q3. Explain Agile Methodology in short. 

Ans. Agile approach is a practise that encourages continuous iteration of development and testing throughout the project’s software development lifecycle. Unlike the waterfall model, both development and testing activities are carried out concurrently. 

Q4. Is it possible to estimate software size before coding? Justify your answer with suitable example. 

Ans. Yes, it is possible to estimate software size before coding. However, a correct estimate may not be possible based on LOC (line of code). 

• (a) By comparing it to current systems of the same type, the size of the programme can be estimated. 
• (b) Experts use it to anticipate the required size of various software components, which they then combine together to obtain the entire size. 
• (c) Estimating the LOC by evaluating the problem specification is quite challenging. After all of the code has been written, an exact LOC may be estimated. 

Q5. Compare development testing with regression testing. 

Ans. Comparison of Development and Regression Testing Techniques 

Section B: Software Engineering Short Question Answer

Q6. How does ‘Project Risk’ factor affect the spiral model of software development?

Ans. A risk is any negative scenario that could jeopardise the successful execution of a software project. The spiral model’s most critical characteristic is dealing with unexpected risks once the project has begun. Such risk resolutions are made easier by creating a prototype. The spiral approach facilitates risk management by allowing for the creation of a prototype at each stage of software development.  

The prototype paradigm also enables risk management, although hazards must be fully identified before the project’s development activity begins. However, in real life, project risks may arise after development work has begun; in this scenario, the prototype paradigm cannot be used. The attributes of the product are dated and assessed in each phase of the spiral model, and the risks at that moment in time are identified and resolved through prototyping. As a result, this model is far more adaptable than existing SOLC models. 

Q7. What is the difference between SRS document and Design document? What are the contents of both the documents? 

Ans. Difference between SRS Document and Design Document: The SRS is a contract between the customer and the development team. After the client has authorised the SRS document, any following disagreements are resolved by referring to the SRS document. The SRS document specifies the requirements of the client in terms of features, performance, external interfaces, and design limitations. SRS is made up of functional, non-functional, user, interface, and system components. 

A design’s goal is to define how the improvements will be implemented into the existing project. It should include finished product examples. This could contain screenshots of navigational mechanisms such as exporting and component diagrams. 

Design includes: E-R diagrams, data flow diagrams and data dictionary. 

Format of SRS: At the end of the analytical task, the software requirements specification is created. As part of system engineering, the function and performance assigned to software are refined by establishing a thorough information description, a precise functional description, a representation of system behaviour, proper validation criteria, and other information important to requirements. 

The SRS document should be organised into the following sectiohs’and each of these sections should discuss the items mentioned under the respective section heading:  

• (a) Introduction
  • (i) Purpose 
  • (ii) Scope 
  • (iii) Definition
• (b) Functional Requirements 
  • (i) Functional requirements 
  • (ii) Functional description 
  • (iii) Control description
• (c) Non-functional Requirements 
• (d) Behavioural Description 
  • (i) System states 
  • (ii) Events and actions  
• (e) Validation criteria 
  • (i) Performance bounds 
  • (ii) Classes of tests 
  • (iii) Special considerations

Format of Design Document: A design document describes a problem’s solution. Because the nature of each problem is unique, you naturally wanted to format your design document differently. 

The design document should be organised into the following sections and each of these sections should discuss the items mentioned under the respective section heading. 

• (a) Title and People 
• (b) Overview 
• (c) Context 
• (d) Goals and non-Goals 
• (e) Milestones 
• (f) Existing Solutions 
• (g) Proposed Solutions 
• (h) Alternative Solutions 
• (i) Testability, Monitoring and Alerting 
• (j) Cross-Team Impact. 
• (k) Open Questions 
• (l) Detailed Scoping and Timeline

Q8. What are the characteristics to be considered for the selection of life cycle model? Explain clearly. 

Ans. Following are the characteristics to be considered for the selection of life cycle model: 

• (a) Feature-based: The software development lifecycle is structured around application features rather than tasks. The functionality developed during an iteration based on the customer’s priorities is referred to as a feature. When users provide input, features might evolve over numerous iterations. 
• (b) Risk-driven: In software development, the iterations are driven by identifying and evaluating the critical risks. 
• (c) Iterative: The software development lifecycle is iterative and focuses on frequent releases in order to obtain feedback, assimilate the resulting learning and setting the right direction for further development. 
• (d) Change-tolerant: Software development is change-tolerant, viewing change as the ability to incorporate competitive advantage, but not as a problem for development. 
• (e) Mission-focused: The overall purpose that guides the team is adequately specified for many projects, even if the requirements are ambiguous at the start. A mission, rather than a set destination, establishes boundaries. Mission statements, as well as the talks that lead to them, provide guidance and criteria for making crucial project tradeoff decisions.

Without a clear mission and a constant mission refinement practice, iterative lifecycles become oscillating lifecycles, swinging back and forth with no progress in the development.

Section C: Software Engineering Detailed Question Answers

Q9. Define module coupling and explain different types of coupling in detail. 

Ans. Module Coupling

Module coupling is the process of connecting two or more modules to each other and to the outside environment. It generally depicts how the modules are linked to one another and to the outside world. Cohesion is connected to coupling. Data concealing can be accomplished with the help of cohesiveness since the cohesive module does only one task or one element in the total software method with a minimal amount of interaction with other modules. Low coupling is associated with high cohesiveness. The lower the coupling, the higher the cohesion, and the better the programme, and these programmes can be regarded to be functionally independent of other modules.

Types of Coupling: There are three types of couplings as follows:

• 1. Normal Coupling: In the normal coupling data is passed across modules through parameters. Data can be passed across modules in one of the three ways: 
  • (a) Data Coupling: In data coupling, data is passed across modules through parameters. The parameters must be in elementary form of data. 
  • (b) Stamp Coupling: In stamp coupling, the group data is passed across modules. 
  • (c) Control Coupling: Control coupling is utilised when a module performs multiple functions, but only one of them must be performed at any one time. Assume you’ve created a generic module that adds, updates, deletes, prints, and displays records from a given dataset. At any given time, you can only do one of the above.   
• 2. Common Coupling: Two modules are common coupled if they share same global data area. This coupling refers to use of common system area either in RAM or Hard Disk, i.e. one module writes in area and other modules read it from that area. 
• 3. Content Coupling: If two modules share their codes, then they are called content coupled, the interfacing between modules is a series of path work across modules.

The degree of coupling is in ascending order from data coupling to content coupling. Data coupling is lowest in the coupling and hence, it is the best for structural programming. 

Q10. Describe in detail the complete software maintenance process. 

Ans. Software Maintenance: The process of altering software after it has been provided to the customer is known as software maintenance. programme maintenance is a comprehensive activity that encompasses error corrections, capability increases, capability removals, and optimisation. Any work done to update the programme after it has been operational is considered maintenance work. 

In software engineering, software maintenance is the modification of a software product after it has been delivered to rectify flaws, improve performance or other features, or adapt the product to a changed environment.

Process of Software Maintenance

This international standard describes the six software maintenance processes as:

• 1. The implementation processes include software preparation and transition activities such as the conceptualization and design of the maintenance plan, preparation for dealing with difficulties discovered during development, and product configuration management follow-up. 
• 2. The problem and modification analysis procedure, which is carried out once the application has been assigned to the maintenance group. The maintenance programmer must examine each request, confirm it (by duplicating the scenario) and check its correctness, analyse it and provide a solution, document the request, and lastly secure the necessary approvals to implement the changes. 
• 3. The process considering the implementation of the modification itself.  
• 4. The update is accepted by confirming with the individual who submitted the request to ensure that the modification provided a solution. 
• 5. The migration process (for example, platform migration) is exceptional and is not part of daily maintenance duties. This procedure will be utilised if the product must be moved to another platform without any changes in functionality, and a maintenance project team will most likely be allocated to this work. 
• 6. Finally, the retirement of a piece of software is a maintenance operation that does not occur on a daily basis. 

Q11. Explain all levels of COCOMO model. Assume that the size of an organic software product has been estimated to be 32,000 lines of code. Determine the effort required to develop the software product and the nominal development time.

Ans. Levels of COCOMO Model  

COCOMO consists of a hierarchy of three increasingly detailed and accurate levels. Any of the three levels can be adopted according to our requirements. These three levels of COCOMO model are as follows: 

(a) Basic COCOMO Model: The first level, Basic COCOMO can be used for quick and slightly rough calculations of Software Costs. Its accuracy is somewhat restricted due to the absence of sufficient factor consideration. 

E = a(KLOC)^b and D = c(E)^d 

The above formulae are used for the calculation of efforts applied in person-months and development time in months of the basic COCOMO model. They are also used in the subsequent models. The constant values a, b, c and d for the basic model for the different categories of system are:

The effort is measured in Person-Months and, as the calculation indicates, is reliant on Kilo-Lines of code. These formulas are utilised in the Basic model calculations since diverse elements such as reliability and competence are not taken into account, hence the estimate is approximate. 

(b) Intermediate COcOMO Model: The foundation The COCOMO model posits that effort is just a function of the number of lines of code and some constants that vary depending on the software system. However, no system’s effort and timetable can be calculated exclusively on the basis of lines of code. Other qualities such as dependability, experience, and capability are also taken into account. These are known as Cost Drivers, and the Intermediate model employs 15 of them for cost estimation. 

Classification of Cost Drivers and their attributes: 

• (i) Product Attributes:
  • a. Required software reliability extent.
  • b. Size of the application database.
  • c. The complexity of the product. 
• (ii) Hardware Attributes: 
  • a. Run-time performance constraints.
  • b. Memory constraints.
  • c. The volatility of the virtual machine environment. 
  • d. Required turnabout time.  
• (iii) Personnel Attributes:
  • a. Analyst capability.
  • b. Software engineering capability.
  • c. Applications experience.
  • d. Virtual machine experience.
  • e. Programming language experience. 
• (iv) Project Attributes:
  • a. Use of software tools.
  • b. Application of software engineering methods.
  • c. Required development schedule.  

The project manager is to rate these 15 different parameters for a particular project on a scale of one to three. Then, depending on these ratings, appropriate cost driver values are taken from the above table. These 15 values are then multiplied to calculate the EAF (Effort Adjustment Factor). The Intermediate COCOMO formulae now takes the form. 

E = (a(KLOC)^b)* EAF

The values of a and b in case of the intermediate model are as follows:  

(c) Detailed COCOMO Model: Detailed COCOMO also considers the impact of various project stages, i.e., in the case of detailed, it considers both of these cost drivers, and calculations are now performed phase by phase, yielding a more accurate conclusion. 

Detailed COCOMO incorporates all intermediate version attributes as well as an assessment of the cost driver’s impact on each phase of the software engineering process. For each cost driver attribute, the detailed model employs a distinct effort multiplier. The entire software is divided into different modules in detailed COCOMO, and then we apply COCOMO in each module to estimate effort and then sum the effort. The six phases of detailed COCOMO are: 

• (i) Planning and requirements 
• (ii) System design 
• (iii) Detailed design 
• (iv) Module code and test 
• (v) Integration and test 
• (vi) Cost constructive model 

 The effort is calculated as function of program size and a set of cost drivers are given according to each phase of the software lifecycle. 

Numerical: Given: KLOC =32,000 lines of code

Since the software project is organic, 

a = 2.4, b = 1.05, c = 2.5, d = 0.38  

Efforts required, E = a(KLOC)b 

= 2.4 (32000)^1.05  

= 1,29,008.62 person-months  

Nominal development time, D = c(E)^d 

= 2.5 (129008.62)^0.38 

= 218.76 (opp.) months

Q12. Describe ‘Rapid Application Development’ (RAD) model in detail. 

Ans. Rapid Application Development (RAD) is a software development paradigm that emphasises a very short development cycle. The RAD model is a high-speed adaption of the linear sequential model that uses a component-based construction strategy to accomplish quick development. If the requirements are adequately defined, the RAD paradigm allows a development team to quickly produce a fully functional solution. A model number of teams can work on a single project in RAD. A distinct Rapid Application Development team can create major functions that are subsequently combined to form a whole. The construction of reusable programme components is emphasised in RAD. All types of applications are not appropriate for RAD model. High performance cannot be achieved by RAD model. 

It is a high-speed adaptation of the linear sequential paradigm that allows for quick development through the use of component-based construction. Using this methodology, fully working software can be created in as little as 60-90 days. The only constraint is clearly defined recruitment specifications. The speed of operations is achieved by the use of reusable software code. Software produced in JAVA beans is an excellent example of software mode using RAD. We can term it a ‘Rapid’ linear sequential model, with the only distinction being that the waterfall approach emphasises achieving the proper design first, whereas rapid prototyping emphasises frequent modifications and discarding the inappropriate design. RAD approach consists of following phases.  

• (a) Business Modelling: Under business modelling the following functions are covered:  
  • (i) What information driven the business process?
  • (ii) What information is generated and who generate it? 
  • (iii) Where does information go?
  • (iv) Who processes it?
• (b) Data Modelling: The above-mentioned information flow is refined into a set of data items required to serve the company. Each object’s qualities, known as attributes, are identified. The objects’ relationships are also defined. 
• (c) Process Modelling: This phase is primarily focused with translating the data model created during the data-modeling phase into the information flow required to implement the business functions. This phase also includes data object administration responsibilities such as adding, deleting, and changing data. 
• (d) Application Generation: The core technique underpinning RAD application generation is the usage of reusable software components. Automated tools are employed or produced if not already present in the existing library for speedy software development. 
• (e) Testing: Since most of the application development is done with reusable pieces of software, Substantial amount of testing is eliminated. Though the new bits added should be tested and all interfaces must be fully exercised.

Advantages of RAD Model: These are as follows: 

• (a) It follows a modular approach for development.
• (b) RAD model is very useful for very short time perio
• (c) It advocates the use and development of reusable components.

Disadvantage of RAD Model: These are as follows 

• (a) All types of applications are not appropriate for RAD model. 
• (b) This model also demands commitment to rapid-fire activities from both customers and developers. 
• (c) For large and medium size projects RAD model requires sufficient human resources. 
• (d) RAD approach may not work when technical risks are high.  

Q13. (i) What are the limitations of waterfall model? 

Ans. Following are the limitations of waterfall model: 

• (a) Real-world projects rarely follow the model’s proposed sequential sequence. 
• (b) It is critical to begin by gathering all of the knowledge required for project planning.
• (c) The Waterfall process paradigm requires a complete set of user requirements before beginning design. It is frequently difficult for the consumer to express all of his or her expectations explicitly. 
• (d) Leads to the creation and development of a vast amount of unusable code. 
• (e) It is devoid of any form of risk assessment. 
• (f) Until the system arrives, neither the user nor management can tell how good or awful it is. The user may not have the opportunity to progressively become accustomed to the system. 
• (g) Working software is not available until relatively late in the process. 

(ii) How some of the limitations of waterfall model are overcome by iterative methods?

Ans. Iterative models have been developed to overcome the limitations of the waterfall model because it involves construction and delivery of software in phases. 

The limitations of waterfall model are overcome in the following ways: 

• (a) Each iteration of the iterative model delivers a product having incremental capabilities. 
• (a) The iterative model produces an operational quality product at each release that only meets a subset of the client requirements. 
• (c) An iterative paradigm can lead to improved testing because evaluating each increment is likely to be simpler than testing the entire developed software system. 
• (d) The consumer is not required to pay for the complete software at once. 
• (e) An iterative model is beneficial when personnel is insufficient for the project’s entire implementation by the business deadline.
• (f) Payment for the whole suite of software is not required at once. Before the programme is upgraded with extra capabilities, the major part of it can be produced and a cost benefit analysis can be undertaken.