Management of Software Systems CST309 is a KTU S5 CSE 2019 scheme course. Here the model questions given in the university syllabus is solved and discussed. his course provides fundamental knowledge in the Software Development Process. It covers Software Development, Quality Assurance, Project Management concepts and technology trends. This course enables the learners to apply state of the art industry practices in Software development.
| Board | KTU |
| Scheme | 2019 New Scheme |
| Year | Second Year |
| Semester | S5 Computer Science |
| Subject | CST 309 | Management of Software Systems |
| Type | Model Question Paper Solved |
| Category | KTU S5 Computer Science |
We strive to provide you with qualified and up-to-date study resources in order to fulfil our mission. The answer key for the KTU MSS MODEL QUESTION PAPER in the syllabus is available here. Work hard and don't forget to share with your friends.
--------------------------------------------------------
MSS Model Question Paper Solved | 2019 Scheme
APJ ABDUL KALAM TECHNOLOGICAL UNIVERSITY FOURTH SEMESTER B.TECH DEGREE EXAMINATION
Course Code: CST 309
Course name: Management of Software Systems
Max Marks: 100
Duration: 3 Hours
PART-A
(Answer All Questions. Each question carries 3 marks)
(10x3=30)
1. Why professional software that is developed for a customer is not simply the programs that have been developed and delivered.
Ans 1:
- Professional software that is developed for a customer is not simply the programs because professional software is nearly often delivered with related documentation such as specifications, design models, and user manuals, it is not only the programmes generated for a customer.
- A decent or professional piece of software goes beyond that which is created purely for the benefit of a consumer.
- It is usually made comprised of executable code as well as documentation and data configuration needed to make these applications work properly.
2. Incremental software development could be very effectively used for customers who do not have a clear idea about the systems needed for their operations. Justify.
Ans 2:
- Software is produced and tested incrementally in the incremental approach, meaning that features are added after each test until the finished product is delivered to the customer's satisfaction.
- It incorporates aspects of both the waterfall and prototyping models.
- Customers that do not have a clear system requirement at the outset will benefit from incremental development since they will be able to see the features developed early in the development cycle, review them, and make suggestions for additional modifications.
- Interacting with the earliest prototypes or increments can provide insight into the path their system should follow.
3. Identify any four types of requirements that may be defined for a software system
Ans 3:
System requirements, in general, are meant to communicate the functions that the system should provide. And all computer-based systems have a long list of criteria.
- User requirements: User requirements consist of natural language assertions as well as diagrams of the system's services and operational restrictions.
- System requirements: A structured document describing the system's functions, services, and operational limitations in detail. Defines what has to be done. It could be stipulated in a contract between the client and the contractor.
- Functional requirements: These are statements about the services the system should deliver, how it should react to specific inputs, and how it should behave in specific situations.
- Non-functional requirements: Restrictions on the system's services or functions, such as time limitations, development process constraints, standards, and so on.
4. Describe software architecture
Ans 4:
- Software architecture is the way a system is organised.
- This organisation covers all components, how they interact with one another, the operating environment, and the software design principles.
- It can also involve the software's evolution in the future in many circumstances.
- The architecture of the software is created with a specific objective or set of missions in mind.
- That mission must be carried out without interfering with the missions of other instruments or devices.
- The behaviour and structure of software have a big impact on decisions, thus they must be rendered and created properly for the greatest results.
5. Differentiate between GPL and LGPL?
Ans 5:
- The basic difference between GPL and LGPL is that GPL gives software users additional protection. It gives them the ability to modify the software, as well as share and receive source code.
- When a user distributes software, they must ensure that others have the same rights as they do. It's worth noting that any modifications to the software must likewise be licenced under the GPL.
- LPGL is designed for software libraries that can be modified and returned source codes, but can also be linked to a non-free programme that is not licenced under the GPL. While most programmes nowadays are GPL-licensed, and most libraries are GPL-licensed, some libraries choose to utilise LGPL so that more users can benefit from it.
6. Compare white box testing and black box testing.
Ans 6:
| Black Box Testing | White Box Testing |
| It's a type of software testing in which the program's or code's internal structure is hidden and nothing is known about it. | It is a method of software testing in which the tester is familiar with the software's internal structure, code, or program. |
| It is frequently done by software testers. | It is frequently done by developers. |
| It is not necessary to have any prior experience with implementation. | Implementation expertise is necessary. |
| It's also known as "outer" or "external" software testing. | Internal software testing is what it's called. |
| It is a software functional test. | It is a software structural test. |
| On the basis of the requirement specifications paper, this testing can begin. | This form of software testing begins once the detailed design document has been completed. |
7. Specify the importance of risk management in software project management?
Ans 7:
- Effective risk management solutions enable you to recognize the strengths, weaknesses, opportunities, and dangers that your project faces.
- Define how you will handle any risks to guarantee that you can recognize, minimize, or eliminate problems as they arise to ensure the success of your project.
- Risk management is crucial to successful project managers since accomplishing project goals is dependent on planning, preparation, results, and evaluation, all of which contribute to achieving strategic goals.
- Effective risk management makes it easy to deal with issues and ensures that they do not result in budget or schedule delays.
- Because of the inherent uncertainties in software development, software risk management is critical.
8. Describe the COCOMO cost, estimation model.
Ans 8:
- The COCOMO 2 model is the Extendend version of (COCOMO-81)
- COCOMO 2 recognizes different approaches to software development such as prototyping, development by component composition, and use of database programming.
- COCOMO II supports a spiral model of development and embeds several sub-models that produce increasingly detailed estimates.
- These can be used in successive rounds of the development spiral.
9. Discuss the software quality dilemma
Ans 9:
The problem with quality is essentially twofold:
- Build low-quality software, and no one will want to buy or use it.
- Spend too much time on quality standards, and no one will buy or utilise it since it is either too expensive or still under development.
- The pace with which software is released, the fidelity of the feature set, and the quality of the underlying code base are all important aspects of any software project. In an ideal world, it should be in the middle, as shown in the following figure
- As we come closer to one goal, we tend to move away from the others, as shown by the triangle. When it comes to speed, for example, quality and feature authenticity are sacrificed to some extent.
10. List the levels of the CMMI model?
Ans 10:
Maturity level indicates the level of process capability:
o Initial
o Repeatable
o Defined
o Managed
o Optimizing
PART-B
(Answer any one question from each module. Each question carries 14 Marks)
11. (a) Compare waterfall model and spiral model(8)
(b) Explain Agile ceremonies and Agile manifesto(6)
Ans 11(a):
| Waterfall Model | Spiral Model |
| The waterfall paradigm operates in a sequential manner | spiral model, on the other hand, is based on the evolutionary process |
| The waterfall model identifies and corrects faults or errors once each stage is completed. | Errors or dangers are discovered and corrected early in the spiral model |
| The waterfall approach can be used for a small project. The waterfall model necessitates early-stage planning and requirements | For large projects, the spiral model is employed.. |
| Customers are using the Waterfall model. | Developers are using the spiral model. |
| In the waterfall model requirements and early-stage planning is needed. | While in spiral model requirements and early-stage planning is necessary if needed. |
| Flexibility in a waterfall model is hard. | The spiral model's flexibility to modify is comparatively easy. |
| The waterfall model carries a significant level of risk | In the spiral model, there is a low level of risk |
| The waterfall model is a relatively low-cost option | The spiral model, on the other hand, is somewhat costly. |
Ans 11(b):
Agile ceremonies:
Agile ceremonies are meetings with set durations, frequency, and objectives. Their goal is to assist project teams in planning, tracking, and engaging stakeholders in their work, as well as reflecting on how well they've collaborated. They're usually part of the Agile Scrum framework.
4 key Agile ceremonies
1. Sprint planning ceremony
- The purpose is to describe the sprint's desired outcome, define which backlog items may be completed, and determine how to execute each item.
- The complete Scrum team, including the Product Owner, is invited to attend.
- This ceremony will take place at the start of each sprint, normally every 1–4 weeks, depending on the length of the sprint.
- The maximum length is 2–6 hours, depending on the length of the sprint
2. Daily Scrum ceremony
- The goal of this ceremony is to ensure the project team has shared visibility of how the
- sprint is progressing Project team, Product Owner (optional), and Scrum Master are among the attendees (optional)
- This ritual occurs on a daily basis.
- This ceremony will last no more than 15 minutes.
3. Sprint review
Goal: discuss and demo work completed, celebrate and highlight accomplishments, and
determine next actions
Participants: entire Scrum team, Product Owner, business stakeholders
Frequency: end of each sprint, typically every 1–4 weeks
Length: up to an hour per week of the sprint, i.e., 2-hour meeting for a 2-week sprint
4. Sprint retrospective
Goal: understand what worked and what didn’t in the last sprint, with a focus on increasing quality and effectiveness
Participants: entire project team
Frequency: end of each sprint, usually every 1–4 weeks Length: as long as is required, 2–3 hours is about average
Agile manifesto
• By doing it ourselves and helping others do it, we're discovering better ways to develop software.
We have learned to cherish the following things as a result of our work:
"Over processes and tools, it's about people and their interactions. Working software trumps thorough documentation. Collaboration with customers is preferred over contract negotiations. Adapting to change in accordance with a strategy"
that is, while there is value in the items on the right, we value the items on the left more.
12. (a) Illustrate software process activities with an example. (8)
(b) Explain Agile Development techniques and Agile Project Management (6)
Ans 12(a):
A software process is a series of interconnected actions that leads to software production. These efforts could include creating software from the ground up or changing an existing system.
Any software process must include the following four activities:
- Software specification (or requirements engineering): Define the main functionalities of the software and the constraints around them.
- Software design and implementation: The software is to be designed and programmed.
- Software Verification and validation: The software must conform to its specification and meet the customer's needs.
- Software evolution (software maintenance): The software is being modified to meet customer and market requirements changes.
Examples: • The waterfall model • The spiral model (Can explain any model)
Ans 12(b):
| Step | Phase | Description |
| Step 1 | Define | Determine what work will be done in the current iteration |
| Step 2 | Design | Plan how to build the requirements into a product |
| Step 3 | Build | Make the design a reality |
| Step 4 | Test | Verify the product functions as designed |
| Step 5 | Release | Give the product to the customer |
Agile Project Management
- Agile Project Management is one of the most groundbreaking methodologies for project management that has been offered.
- This is one of the most recent projects management methodologies, and it is primarily used in software development project management. When learning about agile project management, it's best to think about it in terms of the software development process.
- There have been a number of methods in place since the beginning of software development as a company, such as a waterfall model.
- Traditional models are no longer robust enough to meet the demands of software development, technology, and business requirements.
- As a result, more flexible software development approaches were necessary to address the requirements' adaptability.
- In an agile project, managing the team is the duty of the entire team, not just the project manager. In terms of processes and procedures, common sense takes precedence over stated policies.
- This ensures that managerial decision-making is not delayed, allowing things to move forward more quickly.
- The agile project management position should display leadership and motivational skills in addition to being a manager. This aids in the retention of team spirit and encourages the team to adhere to discipline.
13. (a) What are functional and non-functional requirements? Imagine that you are developing a library management software for your college, listing eight functional requirements and four nonfunctional requirements. (10)
(b) List the components of a software requirement specification? (4)
Ans 13(a):
Functional Requirements: These are the needs that the end-user expresses as essential features that the system should provide. As part of the contract, all of these functionalities must be included in the system. These are expressed or described as input to be delivered to the system, operation to be conducted, and expected output. They are the user's expressed requirements that, unlike non-functional criteria, can be seen immediately in the completed product.
Non-functional requirements: These are the quality requirements that the system must meet in order to fulfil the project contract. The importance of these aspects, as well as the amount to which they are implemented, varies from project to project. Non-behavioural requirements are another name for them.
FUNCTIONAL REQUIREMENTS OF LIBRARY MANAGEMENT SYSTEM Project
Only genuine users should have access to the system.
Only the user should be able to contribute library-related information.
The user must be able to do the following: • Provide book information.
- Use the database to find the required books.
- Update the database with a new book.
- Update the database's book count.
- Enter the data from the issued book into the database.
- Information about books that have been returned.
The number of copies of a book must be known by the user.
It is not permitted to use the same ID for two or more books.
Before issuing, the user must check to see if the book is available.
In the database, the user must input the issue and return dates.
The user must be aware of the library's shelf count.
Ans 13(b):
The components of the Software Requirements Specification (SRS) document are:
- Functional requirements of the system
- Non-functional requirements of the system, and
- Goals of implementation
1. Functional Requirements: Functional requirements explain what output should be generated
from the inputs provided. As a result, they essentially characterise the system's connectedness
between its input and output.
2. Non-functional requirements of the system: Non-functional requirements cover system qualities
that can't be stated as functions, such as system maintainability, movability, and usability. The
following are examples of non-functional requirements:
a. Issues with dependability
b. Results precision
c. Problems with the human-computer interface. Implementation constraints
3. Goals of Implementation: The section on implementation goals outlines some broad development
recommendations. These tips will help you decide which style goals to prioritise. The implementation
section's goals could include documenting issues such as future system functionalities that will be
required, new devices that will be supported in the future, reusability issues, and so on. These are the
considerations that developers may have during development in order for the produced system to meet
some aspects that may not appear to be required right away.
OR
14. (a) Explain Personas, Scenarios, User stories and Feature identification? (8)
(b) Compare Software Architecture design and Component level design (6)
Ans 14(a):
Personas:
- A persona is a description of a product or service's target user. A persona is a fictional character who represents the target user's background, ambitions, and desires in relation to the product.
- The persona allows you to gain a deeper understanding of your target users so that you can build a solution that meets their needs.
- A persona is created using user research data gathered from various users via observations, interviews, and questionnaires, among other methods. The persona, on the other hand, is
- presented as a description of a single person, despite the fact that it represents a collection of users with similar qualities.•
- Because it is simpler to empathise with a description of a specific person rather than a set of statistics describing an entire group, the user data is presented as an individual person.
Scenarios
- Typically, a persona is linked with one or more circumstances. A scenario is a short storey that explains how and why the persona would use the product to fulfil a certain job in a particular situation. For different activities or settings, numerous scenarios could be written.
- A scenario is used to aid the design team in visualising how a target user might interact with the product in the real world. This can aid in establishing the product's functions and features for design requirements, as well as generating usability testing tasks.
User stories
- A user story is a casual, generic explanation of a software feature written from the end user's perspective.
- Its goal is to communicate how a software feature will benefit the customer. It's easy to believe that user stories are nothing more than software system requirements.
Feature identification
- Feature identification is a well-known technique to identify subsets of a program source code activated when exercising a functionality.
Ans 14(b):
| S.No. | Component level design | Software Architecture design |
| 1 | Software design is about designing individual modules/components. | Software architecture is about the complete architecture of the overall system. |
| 2 | Software design defines the detailed properties. | Software architecture defines the fundamental properties. |
| 3 | In general, it refers to the process of creating a specification of software artefact which will help to developers to implement the software. | In general, it refers to the process of creating the high-level structure of a software system. |
| 4 | It helps to implement the software. | It helps to define the high-level infrastructure of the software. |
| 5 | Software design avoids uncertainty. | Software architecture manages uncertainty. |
| 6 | Software design is more about individual modules/components. | Software architecture is more about the design of the entire system. |
| 7 | It is considered as one initial phase of the Software Development Cycle (SSDLC) and it gives a detailed idea to developers to implement consistent software. | It is a plan which constrains software design to avoid known mistakes and it achieves one organization's business and technology strategy. |
15. (a) Explain software testing strategies. (8)
(b) Describe the formal and informal review techniques. (6) OR
Ans 15(a):
- Software testing is a sort of investigation used to determine whether the software contains any defaults or errors so that the errors can be decreased or removed, hence improving the software's quality and determining whether it meets the specified standards.
- The basic goal of software testing is to build tests in such a way that they detect many types of mistakes in a systematic manner with minimal time and effort, allowing for faster software development.
- Before any testing can begin, the product's needs must be identified and specified in a quantitative manner. There are various qualities of software, such as maintainability, which refers to the ability to update and alter, likelihood, which refers to the ability to discover and assess any risk, and usability, which refers to how easily it can be used by consumers or end-users. All of these characteristics should be given in a specific order in order to receive accurate test results.
- Defining the testing goals in a clear and precise manner. There are several testing objectives, including effectiveness, which refers to how well the software achieves the goal, any failure, which refers to the software's inability to meet requirements and perform functions, and the cost of defects or errors, which refers to the cost of correcting the error. All of these goals should be stated explicitly in the test plan.• •
- Identifying the user's category and creating a profile for each user for the software. The interactions and communication among different kinds of users and the system to achieve the goal are described in use cases. In order to determine the users' actual requirements and then evaluate the product's actual use.
- Creating a test plan with a focus on rapid-cycle testing to add value. Rapid Cycle Testing (RCT) is a form of test that enhances quality by detecting and quantifying any adjustments that must be made to improve the software development process. As a result, a test plan is a crucial and useful document that aids the tester in doing rapid cycle testing.
- It is created robust software that is designed to test itself. The software should be able to detect and identify various types of faults. Furthermore, software design should allow for automated and regression testing, which examines the product to see whether any changes in code or programme have an adverse or negative effect on its functionality.
- Use effective formal reviews as a filter before testing. Formal technical reviews are a tool for detecting faults that have not yet been noticed. Effective technical reviews completed prior to testing lower the amount of testing work and time necessary for software testing, reducing the overall development time of software.
- Conduct formal technical reviews to assess the test strategy and test cases' nature, quality, and capability. The rigorous technical evaluation aids in the detection of any gaps in the testing strategy. As a result, technical reviewers must assess the ability and quality of the test strategy and test cases in order to improve software quality.
- Developing a continuous development methodology for the testing process. A test method that has already been measured should be utilised for software testing as part of a statistical process control approach to measure and regulate quality during software development.
Ans 15(b):
Informal reviews
- Informal reviews take place between two or three people. The review conference is scheduled at their convenience.
- This meeting is generally scheduled during the free time of the team members.
- There is no planning for the meeting. If any errors occur, they are not corrected in the informal reviews. There is no guidance from the team. This review is less effective compared to the formal review.
Formal reviews
- Formal reviews take place among a team of three to five members. In the formal review, the members discuss the software model.
- This meeting is scheduled beforehand. This gives the team members time to prepare.
- This meeting consists of a professional team that identifies and corrects errors in the model. This meeting does not exceed two hours.
16. (a) Explain Continuous Integration, Delivery, and Deployment CI/CD/CD) (b) Explain test driven development (8) (6)
Ans 16(a):
| Aspect | Description |
| Continuous integration | Each time a developer commits a change to the project's master branch, an executable version of the system is build and tested. |
| Continuous delivery | A simulation of the product's operating environment is created and the executable software version is tested |
| Continuous deployment | A new release of the system is made available to users every time a change is made to the master branch of the software |
Continuous integration is a software development technique in which team members integrate their work at least once each day. Every integration is checked by an automated build in this approach to look for errors. After a code commit, continuous integration builds and tests the app right away. Commits are made often throughout the day in a large project with numerous developers. Each commit results in the creation and testing of code. The build is then tested for deployment if the test passes. The code gets pushed to production if the deployment is successful. This continuous process of committing, building, testing, and deploying is known as continuous integration/deployment.
Continuous delivery is a software engineering process in which a group of people works together to create software products in a short period of time. It ensures that software can be released at any moment without difficulty. Continuous delivery's major goal is to produce, test, and distribute software at a high rate and frequency. It allows for frequent upgrades in production, which reduces the cost, time, and risk of delivering changes.
Continuous deployment is a software engineering process that uses automatic deployment to offer product functionality. It aids testers in determining whether codebase changes are right and stable. By depending on infrastructure that automates several testing procedures, the team may accomplish continuous deployment. The programme is updated with new code once each integration meets the release criteria.
Ans 16(b):
- TDD (Test Driven Development) is a software development methodology that focuses on establishing unit test cases before writing actual code. It's a method that combines programming, unit testing, and refactoring in an iterative process.
- The Agile manifesto concepts and Extreme programming are the foundations of the TDD approach. The test process, as its name implies, is what propels software development. Furthermore, it is a structural method that allows developers and testers to obtain efficient code that is long-lasting.
- TDD requires developers to begin by writing basic test cases for each feature based on their initial understanding. The main goal of this strategy is to only change or write new code if the tests fail. This eliminates the need for duplicate test scripts.
Three phases of Test Driven Development
- Create precise tests:
To check the functionality of individual features, developers must construct exact unit tests. They must confirm that the test builds before running it. In the vast majority of circumstances, the test will fail. Developers are writing compact tests based on their expectations about how the product will operate, therefore this is a significant failure.
- Correcting the Code:
When a test fails, developers must make the smallest modifications necessary to correct the code so that it can be re-run successfully.
- Refactor the Code:
Check for redundancy or any possible code improvements once the test has been completed successfully to improve overall performance. Ascertain that refactoring has no impact on the program's external behaviour.
17. (a) What is a critical path and demonstrate its significance in a project schedule with the help of a sample project schedule? (b) Explain plan-driven development and project scheduling. (8) (6) OR
Ans 17(a):
Not Available now
Ans 17(b):
Not Available now
18. (a) Explain elements of Software Quality Assurance and SQA Tasks. (b) What is algorithmic cost modelling? What problems does it suffer from when 57 (6)(8) compared with other approaches to cost estimation?
Ans 18(a):
N/A
Ans 18(b):
N/A
19. (a) Explain elements of Software Quality Assurance and SQA Tasks. (8) (b) Illustrate SPI process with an example. (6) OR
Ans 19(a):
N/A
Ans 19(b):
N/A
20. (a) Compare CMMI and ISO 9001:2000. (8) (b) How can Software projects benefit from Container deployment and Microservice deployment?
Ans 20(a):
N/A
Ans 20(b):
N/A
--------------------------------------------------------
You May Like :
| CST 301 Formal Languages and Automata Theory | Click Here |
| CST 303 Computer Networks | Click Here |
| CST 305 System Software | Click Here |
| CST 307 Microprocessors and Microcontrollers | Click Here |
| CST 309 Management of Software Systems | Click Here |
| MCN301 Disaster Management (Non - Credit) | Click Here |
| CSL 331 System Software and Microprocessors Lab | Click Here |
| CSL 333 Database Management Systems Lab | Click Here |
We hope that the question given in the KTU S5 CST 309 Management of software System Solved Model based on the 2019 program will help you in your future tests. If you like this share it with your friends.
"Share KeralaNotes.Com with your friends"
Here is the model question paper for Database Management System (DBMS) course. This question paper is designed for S5 CSE students of KTU.
Management of Software Systems CST309 is a course in the KTU S5 CSE 2019 curriculum. Model questions from the university syllabus are solved and discussed here. This course teaches the basics of the software development process. It covers concepts and technology trends in software development, quality assurance, project management, and project management. This course teaches students how to apply cutting-edge industrial methods to software development.
If you have any queries regarding the KTU S5 Computer Science (CSE) Study Materials, drop a comment below and we will get back to you at the earliest.
