Sample MITS5501 Software Quality Change Management and Testing Report 2

MITS5501 Software Quality, Change Management and Testing Report 2 Sample

This assessment related to the following Unit Learning Outcomes:

ULO1 Adopt specialized quality engineering and assurance procedures to improve the implementation quality and efficiency of software engineering projects using the advanced concepts and principles learnt throughout the unit.

ULO2 Independently develop clearly defined internal quality management approaches by addressing the quality factors and risks that may affect the resulting software development.

ULO3 Evolve peer review process using tools and techniques taught in the unit as well as carry out research on emerging techniques published in literature to further improve the peer review communication process

INSTRUCTIONS:

In this assessment students will work individually to develop Software Quality Assurance plan document. Carefully read the associated CASE STUDY for this assessment contained in the document MITS5501_CaseStudy_2023.pdf. From this Case Study you are to prepare the following:

1. Given the details in the Case Study, what are the software standards, practices, conventions, and metrics need to be used to improve the quality of the final product. You also need to identify the techniques to monitor the compliance of these standards.

2. Identify the tools and techniques used to perform peer reviews and the methods to reduce the risk of failure.

3. Develop a complete software quality assurance plan document based on the given case study. The document should have the following sections. However, you could add other topics based on your assumptions.

Quality Assurance Plan Document

a. Executive Summary

b. System Description

c. Management Section

d. Documentation Section

e. Standards, Practices, Conventions and Metrics

f. Peer reviews plan

g. Testing Methodology

h. Problem Reporting and Corrective action

i. QA Supporting Tools, Techniques and Methods

j. Software configuration management plan.

k. References

l. Appendices

Your report must include a Title Page with the title of the assessment and your name and ID number. A contents page showing page numbers and titles of all major sections of the report. All Figures included must have captions and Figure numbers and be referenced within the document. Captions for figures placed below the figure, captions for tables placed above the table. Include a footer with the page number. Your report should use 1.5 spacing with a 12-point Times New Roman font. Include references where appropriate. Citation of sources is mandatory and must be in the IEEE style. 

Solution

Introduction

This study identifies the issues in the library management system and also help in proposing a solution through a digital library management system that can be created, implemented, and managed to fulfill the requirement of both staff and customers. For Assignment Help, This study includes different sections like the management section, documentation section, standard, practices, convention, and metrics section, review and inspection section, software configuration management plan, Quality Assurance, and testing.

Purpose Section

This section describes what software is included in the package and how it will be used, among other things. It also outlines the phases of each software product's life cycle that the SQA plan will cover. This section provides simple guidance for making sure the SQA strategy is appropriate for the program in question and its development and implementation stages [6].

Reference Document Section

All sources used to create the SQA plan are listed in detail in the Reference Documents section. This compiled document makes it simple to find resources that enhance and elaborate on the plan's primary text. Industry standards, project guidelines, process documentation, and other sources may be cited here to aid in the creation, execution, and assessment of the Software Quality Assurance strategy.

System Description

The Library Management System is an automation tool made for libraries of various sizes. This computerized system allows librarians to keep tabs on book sales, organize student information, and analyze collection depth. The system's central repository for books and member data helps avoid the kinds of problems that plague non-digital archives. In addition to improving library administration efficiency, the reporting module helps administrators with things like student enrolment, book lists, and issue/return data [5].

Figure 1 Entity Relationship Diagram of Library Management System

Management Section

There is a clear chain of command within the project's organizational structure. The Project Manager is responsible for directing the project and making sure it is completed on time, within scope, and budget. System design, coding, and database administration all fall under the purview of the development team, which consists of software developers and database administrators. The system's reliability and effectiveness are monitored by the Quality Assurance group. Feedback and user testing are provided by administrative and library employees.

Documentation Section

The software's governing documentation covers its whole lifespan, from development to maintenance. The Software Requirements Specification (SRS) is the document that first defines the parameters of the project. The project staff and interested parties check this document to make sure it covers everything. The SDD is a document that specifies the system's architecture, algorithms, and interfaces before, during, and after development. The SDD is evaluated by the development staff and domain specialists. The Test Plan and Test Cases papers outline the goals, methods, and anticipated results of the verification and validation processes. Peer evaluations and test execution outcomes are used to determine the level of sufficiency. The dependability and usefulness of the program rely on these papers, which are kept up-to-date by regular reviews, audits, and user feedback channels [1].

Standards, Practices, Conventions and Metrics Section

- Standards: This study will use conventional coding practices, such as those for file naming and commenting, as well as database best practices. Data encryption and privacy shall meet or exceed all applicable global requirements.

- Practices: Scrum, daily stand-ups, and continuous integration are just a few of the Agile development practices that will be used. Git will be used for version management, which will facilitate teamwork throughout development and help in tracking bugs.

- Conventions: We will require that all variables, functions, and database tables adhere to standard, human-readable names. Usability and accessibility guidelines will be taken into account throughout the UI design process.

- Metrics: Important performance indicators, such as system response times, error rates, and user satisfaction surveys, will be outlined. The quality of the code will be evaluated with the help of static analysis software [3].

Reviews and Inspections Section

At essential points in the planning and execution of the project, it will be reviewed and inspected by both technical and management personnel. Code quality and compliance with coding standards will be monitored by technical reviews, while project progress and resource allocation will be evaluated by management reviews. Reviews, walkthroughs, and inspections will be followed up with action items to remedy identified concerns, and approvals will be issued based on their successful completion to guarantee that the project continues to meet its quality goals and remains on schedule.

Software Configuration Management Section

Software configuration management (SCM) is an integral part of software development since it allows for the centralized management of all software and documentation revisions throughout a project's lifetime [4]. The SCMP focuses on the following topics:

1. Configuration Identification: This part of the SCMP defines how software and documentation configurations will be called and labeled. It details how CIs should be named, how versions should be numbered, and how their structure should look. It specifies who's responsible for what when it comes to creating and maintaining these identifiers.

2. Configuration Control: Software and documentation configuration management is outlined in the SCMP. There is a procedure for handling requests for modifications and putting them into effect.

3. Configuration Status Accounting: This section explains the methodology that will be used to track and report on the current state of setups. Specific sorts of status data, such as versioning, release notes, and baselines, are outlined. It also details how often and how to provide progress reports.

4. Configuration Audits: The SCMP specifies the steps to take while performing a configuration audit, whether it be an internal or external audit. It lays out the goals of an audit, the roles of the auditors conducting it, and the measures that should be taken in response to their findings.

5. Configuration Baselines: Sets the standards and methods for determining what constitutes a "configuration baseline," or a stable and officially sanctioned version of the program and documentation. It specifies how to choose, label, and file baselines.

6. Tools and Environment: The source control management (SCM) tools and environments that will be used throughout the project are covered in this section. Version control, bug tracking, and other configuration management technologies are described in depth.

7. Roles and Responsibilities: The SCMP establishes the tasks and functions of the SCM team members. The SCM manager, developers, testers, and other project participants fall under this category. It clarifies who is responsible for configuration identification, control, status accounting, audits, and baselining.

8. Training and Documentation: This document specifies the documentation and training needs of the SCM team. The SCMP, together with the process guidelines and SCM tool user manuals, are all part of the required paperwork.

9. Security and Access Control: This section deals with the topic of SCM-related security and access control. It specifies the rules for controlling access, encrypting data, and other security procedures to ensure the safety of configurations and associated data.

10. Continuous Improvement: Provisions for continuous process improvement are included in the SCMP. It specifies how the results of audits, reviews, and inspections will be included in the ongoing effort to improve SCM procedures.

Problem Reporting and Corrective Action

The program Configuration Management Plan (SCMP) for the project includes detailed instructions for tracking down and fixing bugs and other problems in the program and supporting documentation. The procedure for recording issues, particularly their severity and effect, as well as tracking and assigning them to be fixed, is outlined. It also details the processes involved in identifying problems, conducting investigations, and applying fixes.

Tools, Techniques, and Methodologies Section

Software tools, methods, and methodologies that aid Software Quality Assurance (SQA) are described in detail in the Tools, methods, and Methodologies section. Tools and processes such as Agile or Waterfall may be used for project management, along with other resources like testing frameworks, version systems of control, automated testing tools, peer review platforms, and more.

Code Control Section

Code Control describes the processes and tools used at each step of development to monitor and maintain the controlled versions of the designated program. Both software configuration management and the use of pre-existing code libraries are viable options. The integrity and traceability of software components are protected throughout the development lifecycle by this section's methodical version management of code.

Media Control Section

The Media Control section describes the processes and resources used to track down, organize, and secure the physical media that corresponds to each computer product and its documentation. This includes outlining how to back up and restore these media assets and taking precautions to prevent them from being stolen, lost, or damaged.

Supplier Control Section

In the Supplier Control section, we detail the procedures used to guarantee that third-party developers' code meets all of our expectations. Methods for ensuring that vendors obtain sufficient and thorough specifications are outlined. It specifies the measures to take to guarantee that previously generated software is compatible with the features addressed in the SQA strategy. If the software in question is still in the prototype phase, the provider in question must create and execute their own SQA plan according to the same criteria.

Records Collection, Maintenance, and Retention Section

In the section under "Records Collection, Maintenance, and Retention," the precise SQA records that will be kept are outlined. It specifies the retention period and details the processes and resources needed to create and maintain this record. Acquiring the necessary permissions and developing a strategy for execution are both key parts of putting the SQA plan into action. After the SQA plan has been implemented, an assessment of its efficacy may be performed, guaranteeing the orderly maintenance and storage of crucial documents throughout the project's lifespan.

Testing Methodology

The Testing Methodology section details the overall strategy, specific methods, and automated resources used during software testing. It specifies the various forms of testing (such as unit, integration, system, and acceptability testing) and the order in which they will be executed. Specific testing methods, such as black-box and white-box testing, as well as automated testing tools and frameworks, are described in this section. It assures that the software's functionality, reliability, and performance are tested in a systematic and well-organized manner [2].

References