Software Quality Assurance and Software Engineering
Software Quality Assurance (SQA) is a process that ensures the quality of software products by monitoring and controlling the software development process. It involves various activities that aim to prevent defects, ensure compliance with standards, and improve the overall quality of the software.
SQA activities:
- Error/Defect Collection and Analysis: SQA collects and analyzes error and defect data to better understand how errors are introduced and what software engineering activities are best suited to eliminating them.
- Change Management: SQA ensures that adequate change management practices have been instituted to manage changes to the software and its processes.
- Risk Management: SQA identifies and manages risks associated with the software development process and the software product itself.
- Project Scheduling: SQA ensures that the project schedule is realistic and achievable, and that the project is completed on time and within budget.
- Personnel Planning: SQA ensures that the right people are assigned to the right tasks and that they have the necessary skills and training to perform their jobs effectively.
- Testing: SQA ensures that the software is thoroughly tested to identify and fix defects before it is released to customers.
- Code Reviews: SQA ensures that the code is reviewed and approved by peers and experts to ensure that it meets the required standards and is free from defects.
- Configuration Management: SQA ensures that the software configuration is properly managed and controlled to ensure that the correct version of the software is released to customers.
- Release Management: SQA ensures that the software is released to customers in a controlled and managed manner, and that the release is properly documented and communicated to stakeholders.
- Auditing: SQA conducts regular audits to ensure that the software development process is compliant with the required standards and that the software meets the required quality standards.
- Management Review: SQA ensures that the software development process is reviewed and approved by management to ensure that it meets the required standards and that the software meets the required quality standards.
- Quality Planning: SQA ensures that the quality plan is developed and approved by management to ensure that the software development process is planned and executed according to the required standards and quality standards.
- Quality Control: SQA ensures that the software development process is controlled and monitored to ensure that it meets the required standards and quality standards.
- Quality Assurance: SQA ensures that the software development process is assured and guaranteed to meet the required standards and quality standards.
(A) Risk Mitigation:
- If a software team adopts a proactive approach to risk, avoidance is always the best strategy. This is achieved by developing a plan for risk mitigation.
- For example, assume that high staff turnover is noted as a project risk, rl. Based on past history and management intuition, the likelihood, 11, of high turnover is estimated to be 0.70 and the impact, x1, is projected at level 2. That is, high turnover will have a critical impact on project cost and schedule. To mitigate this risk, project management must develop a strategy for reducing turnover.
- Among the possible steps to be taken are:
- Meet with current staff to determine causes for turnover (e.g., poor working conditions, low pay, and Competitive job market).
- Mitigate those causes that are under our control before the project starts.
- Once the project commences, assume turnover will occur and develop techniques to ensure continuity when people leave.
- Organize project teams so that information about each development activity is widely dispersed.
- Define documentation standards and establish mechanisms to be sure that documents are developed in a timely manner.
- Conduct peer reviews of all work (so that more than one person is “up to speed”).
- Assign a backup staff member for every critical technologist.
(B) Risk Monitoring:
- As the project proceeds, risk monitoring activities commence.
- The project manager monitors factors that may provide an indication of whether the risk is becoming more or less likely.
- In the case of above example where high staff turnover is the risk, the following factors can be monitored
- General attitude of team members based on project pressures.
- The degree to which the team has jelled. Interpersonal relationships among team members.
- Potential problems with compensation and benefits.
- The availability of jobs within the company and outside it.
- To assess whether predicted risks do, in fact, occur,
- To ensure that risk aversion steps defined for the risk are being properly applied;
- To collect information that can be used for future risk.
(C) Risk Management:
- Risk management and contingency planning assumes that mitigation efforts have failed and that the risk has become a reality.
- Continuing the same example, the project is well underway and a number of people announce that they will be leaving. If the mitigation strategy has been followed, backup is available, information is documented, and knowledge has been dispersed across the team.
- In addition, the project manager may temporarily refocus resources and readjust the project schedule to those functions that are fully staffed, enabling newcomers who must be added to the team to get up to speed.
- Those individuals who are leaving are asked to stop all work and spend their last weeks in “knowledge transfer mode.” This might include video-based knowledge capture, the development of commentary documents and/or and/or meeting with other team members who will remain on the project.
- Part of risk management, therefore, is to evaluate when the benefits accrued by the RMMM steps are outweighed by the costs associated with implementing them.
- In essence, the project planner performs a classic cost/benefit analysis. And if they found that the predominant cost factor is backup, management may decide not to implement this step.
Q. Explain task analysis and modeling.
Task Analysis & Modelling : 1) Task analysis can be applied in two ways. An interactive, computer-based system is often used to replace a manual or semi-manual activity. 2) To understand the tasks that must be performed to accomplish the goal of the activity, a human engineer must understand the tasks that humans currently perform (when using a manual approach) and then map these into a similar (but not necessarily identical) set of tasks that are implemented in the context of the user interface. 3) Alternatively, the human engineer can study an existing specification for a computer-based solution and derive a set of user tasks that will accommodate the user model, the design model, and the system perception. 4) Regardless of the overall approach to task analysis, a human engineer must first define and classify tasks. 5) An alternative approach to task analysis takes an object-oriented point of view. 6) The human engineer observes the physical objects that are used by the interior designer and the actions that are applied to each object. 7) The design model for the interface would not provide a literal implementation for each of these actions, but it would define user tasks that accomplish the end result
Q. Explain the steps for component level design.
Data design at the component level focuses on the representation of data structures that are directly accessed by one or more software components. This following is a set of principles that may be used to specify and design such data structures for data specification 1) The Systematic Analysis Principles applied to Function and and reviewed, data objects should be identified, alternative data organizations should be considered, and the impact of data modeling on software design should be evaluated. 2) All Data Structures and the Operations to be Performed on each should be Identified The design of an efficient data structure must take the operations to be performed on the data structure into account. Upon evaluation of the operations performed on the data structure, an abstract data type is defined for use in subsequent software design. Specification of the abstract data type may simplify software design considerably. 3) A Data Dictionary should be Established and used to Define both data and Program Design A data dictionary explicitly represents the relationships among data objects and the constraints on the elements of a data structure. Algorithms that must take advantage of specific relationships can be more easily defined if a dictionary like data specification exists. 4) Low-level Data Design Decisions should be Deferred until late in the Design Process A process of stepwise refinement may be used for the design of data. That is, overall data organization may be defined during requirements analysis, refined during data design work, and specified in detail during component level design. The top-down approach to data design provides benefits that are analogous to a top- down approach to software design major structural attributes are designed and evaluated first so that the architecture of the data may be established. 5) The Representation of Data Structure should be known only to those modules that must make Direct use of the Data Contained within the Structure The concept of information hiding and the related concept of coupling provide important insight into the quality of a software design. This principle alludes to the importance of these concepts as well as “the importance of separating the logical view of a data object from its physical view. 6) A Library of useful Data Structures and the Operations that may be applied to them should be Developed Data structures and operations should be viewed as a resource for software design. Data structures can be designed for reusability. A library of data structure templates (abstract data types) can specification and design effort for data. reduce both 7) A Software Design and Programming Language should support the Specification and Realization of Abstract Data types The implementation of a sophisticated data structure can be made exceedingly difficult if no means for direct specification of th of the structure exists in the programming language chosen for implementation.
Q. Explain the spiral model with a neat sketch. Give its advantages and drawbacks.
The spiral model is a software development life cycle (SDLC) model that combines elements of the waterfall model and iterative model. It is a “meta-model” that provides a systematic approach to identifying and mitigating risks throughout the software development life cycle. The Spiral Model consists of four phases: Planning, Risk Analysis, Engineering, and Evaluation. Each phase is executed in a cyclical manner, with each cycle building on the previous one. The model is risk-driven, meaning that the focus is on managing risk through multiple iterations of the software development process.
Advantages of Spiral Model: 1. Software is produced early in the software life cycle. 2. Risk handling is one of important advantages of the Spiral model, it is best development model to follow due to the risk analysis and risk handling at every phase. 3. Flexibility in requirements. In this model, we can easily change requirements at later phases and can be incorporated accurately. Also, additional Functionality can be added at a later date. 4. It is good for large and complex projects. 5. It is good for customer satisfaction. We can involve customers in the development of products at early phase of the software development. Also, software is produced early in the software life cycle. 6. Strong approval and documentation control. 7. It is suitable for high risk projects, where business needs may be unstable. A highly customized product can be developed using this.
Disadvantages of Spiral Model: 1. It is not suitable for small projects as it is expensive. 2. It is much more complex than other SDLC models. Process is complex. 3. Too much dependable on Risk Analysis and requires highly specific expertise. 4. Difficulty in time management. As the number of phases is unknown at the start of the project, so time estimation is very difficult. 5. Spiral may go on indefinitely. 6. End of the project may not be known early. 7. It is not suitable for low risk projects. 8. May be hard to define objective, verifiable milestones. Large numbers of intermediate stages require excessive documentation.
Q. What are the four P’s of Software Project Management Explain?
For properly building a product, there’s a very important concept that we all should know in software project planning while developing a product. There are 4 critical components in software project planning which are known as the 4P’s namely: 1. People 2. Product 3. Process 4. Project These components play a very important role in your project that can help your team meet its goals and objective. Now, Let’s dive into each of them a little in detail to get a better understanding: 1. People The most important component of a product and its successful implementation is human resources. In building a proper product, a well-managed team with clear-cut roles defined for each person/team will lead to the success of the product. We need to have a good team in order to save our time, cost, and effort. Some assigned roles in software project planning are project manager, team leaders, stakeholders, analysts, and other IT professionals. Managing people successfully is a tricky process which a good project manager can do. 2. Product As the name inferred, this is the deliverable or the result of the project. The project manager should clearly define the product scope to ensure a successful result, control the team members, as well technical hurdles that he or she may encounter during the building of a product. The product can consist of both tangible or intangible such as shifting the company to a new place or getting a new software in a company. 3. Process In every planning, a clearly defined process is the key to the success of any product. It regulates how the team will go about its development in the respective time period. The Process has several steps involved like, documentation phase, implementation phase, deployment phase, and interaction phase. 4. Project The last and final P in software project planning is Project. It can also be considered as a blueprint of process. In this phase, the project manager plays a critical role. They are responsible to guide the team members to achieve the project’s target and objectives, helping & assisting them with issues, checking on cost and budget, and making sure that the project stays on track with the given deadlines.
Q. What is W5HH principle? Explain in brief.
Barry Boehm gave a philosophy that prepares easy and manageable designs or outlines for software projects. He also gave a technique to discuss objectives, management, duties, and technical approach of the project and its necessary resources. Then he named it the W5HH principle when few questions resulted in project properties, definition, and resultant plan to make the project successful. The W5HH principle in software management exists to help project managers guide objectives, timelines, responsibilities, management styles, and resources.
Q. Discuss waterfall model with the help of diagram. Give limitations of it.
The Waterfall model is a linear-sequential software development process that follows a phased approach. It is a simple and easy-to-understand model, where each phase is completed before moving on to the next one. The phases are: 1. Requirements Gathering: Gathering all the requirements from the client. 2. Design: Designing the software architecture and detailed design. 3. Build: Building the software according to the design. 4. Testing: Testing the software to ensure it meets the requirements. 5. Deployment: Deploying the software to the production environment. 6. Maintenance: Maintaining the software after it is deployed.
The limitations of the Waterfall model are: 1) Rigidity: The Waterfall model is inflexible and does not allow for changes to be made once a phase is completed. 2) No feedback loop: There is no feedback loop between the phases, which means that any errors or issues found during testing cannot be easily corrected. 3) High risk: The Waterfall model is high-risk because it does not allow for flexibility or adaptation to changes in the project requirements. 4) Limited stakeholder involvement: The Waterfall model does not allow for much stakeholder involvement, which can lead to a lack of understanding and buy-in from the stakeholders. 5) No prototyping: The Waterfall model does not allow for prototyping, which can make it difficult to test and validate the software requirements. 6) No iteration: The Waterfall model does not allow for iteration, which means that the software is not tested and validated until the end of the development process. 7) Limited scalability: The Waterfall model is not scalable, as it is designed for small to medium-sized projects and can become unwieldy for large projects.
Q. Define “Software engineering” and describe the different layers in the software engineering technology?
Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software. It is a fully layered technology, where each layer builds upon the previous one, and each layer demands the fulfillment of the previous layer. The different layers in software engineering technology include: 1. A Quality Focus: This layer is the fundamental layer for software engineering. It defines the continuous process improvement principles of software, emphasizing efficiency, usability, maintenance, and reusability. A quality focus is essential to ensure that the end product meets its specifications. 2. Process: It is the foundation or base layer of software engineering. It is key that binds all the layers together which enables the development of software before the deadline or on time. Process defines a framework that must be established for the effective delivery of software engineering technology. The software process covers all the activities, actions, and tasks required to be carried out for software development. Process activities are listed below:- • Communication: It is the first and foremost thing for the development of software. Communication is necessary to know the actual demand of the client. • Planning: It basically means drawing a map for reduced the complication of development. Modeling: In this process, a model is created according to the client for better understanding. • Construction: It includes the coding and testing of the problem. • Deployment:- It includes the delivery of software to the client for evaluation and feedback. 3. Methods: This layer encompasses a broad array of tasks that include communication, requirements analysis, design modeling, program construction, testing, and support. Software engineering methods rely on the set of modeling activities and other descriptive techniques to develop software. 4. Tools: Software engineering tools provide a self-operating system for processes and methods. Tools are integrated which means information created by one tool can be used by another.