Software Development and Testing Techniques for Key Systems
Library Information System: SRS
Introduction
The Library Information System (LIS) automates library functions such as book issue, return, and search, allowing users to manage library operations efficiently.
Assumptions
- The system supports both students and staff members.
- Users can search, issue, return, and renew books.
- The system maintains a record of issued books, return dates, and overdue books.
System Features
- User Management: Register, login, and manage users (students, staff).
- Book Catalog: Display available books, manage categories, and search options.
- Book Issue/Return: Issue, return, and renew books with due date tracking.
- Search Functionality: Users can search books by title, author, or ISBN.
- Notifications: Alerts for overdue books and new arrivals.
External Interfaces
- Hardware: Computer, printer for receipts.
- Software: Database management system (e.g., MySQL).
Functional Requirements
- Add/Edit/Remove book details.
- User registration and login functionalities.
- Issue/Return book with tracking.
Non-functional Requirements
- Performance: The system should handle up to 500 concurrent users.
- Security: Secure login with password encryption.
Solution Design Methods in Function-Oriented Design
Function-Oriented Design focuses on dividing the system into functions or processes that perform specific tasks. It is structured around the flow of data and its transformation through different functions.
Steps
- Data Flow Diagrams (DFDs): Represent how data moves within the system.
- Structure Charts: Hierarchical breakdown of system functions.
- Functional Decomposition: Breaking down a large function into smaller, manageable functions.
Black Box Testing vs. White Box Testing
- Black Box Testing: Focuses on testing the system’s functionality without knowing the internal code structure. Examples include functional and acceptance testing.
- White Box Testing: Involves testing the internal workings of the application, like logic and code flow. Examples include unit and integration testing.
Gantt Chart for Library Information System
A Gantt chart for developing a Library Information System includes tasks such as:
- Requirement Analysis (2 weeks)
- System Design (3 weeks)
- Coding (5 weeks)
- Testing (4 weeks)
- Deployment (2 weeks)
- Maintenance (Ongoing)
Rules to Create a Use Case
- Identify Actors: Identify the users or external systems interacting with the system.
- Define the System’s Goal: What does the user want to achieve?
- Detail Preconditions: Conditions that must be true before the use case can start.
- Create Main Flow: Describe the typical interaction between the actor and the system.
- Handle Alternatives: Include alternative scenarios and exceptions.
Example: In the “Library Information System”, a use case for “Issue Book” includes the student actor, steps to search and issue a book, and exception handling for unavailable books.
Testing Technique: Boundary Value Analysis
Boundary Value Analysis is a testing technique focusing on the values at the boundary of input ranges. It identifies errors at the edges of input conditions.
Test Case for Library Information System
- Test Case 1: Issue a book with no overdue books (valid).
- Test Case 2: Attempt to issue a book with overdue books (invalid).
IEEE SRS Format for Student Admission System
The Software Requirements Specification (SRS) is a comprehensive document that outlines the functionality, design constraints, and system requirements for the software being developed. The IEEE SRS format is a standard format used to structure these specifications.
IEEE SRS Format Sections
- Introduction: Overview of the system, its objectives, and scope.
- Overall Description: High-level description of the system’s behavior, user needs, and constraints.
- System Features: List of functional requirements describing what the system must do.
- External Interfaces: Description of external systems, hardware, or software that interact with the system.
- System Attributes: Non-functional requirements, such as performance, security, and reliability.
- Other Requirements: Any additional system-specific or domain-specific requirements.
SRS for Student Admission System
Introduction
The Student Admission System (SAS) automates the process of student admission, including form submission, document verification, payment processing, and student enrollment.
Assumptions
- The system supports students, administrators, and staff.
- Students can submit applications online, upload documents, and track application status.
- Administrators can review applications, approve or reject students, and generate reports.
System Features
- Student Registration: Students can create accounts, submit applications, and upload documents.
- Application Review: Administrators review applications, approve/reject, and notify students.
- Payment Processing: Integrated payment gateway for tuition fee submission.
- Reporting: Generate reports of applications, fees, and enrolled students.
External Interfaces
- Hardware: User devices (PC, tablet).
- Software: Database (e.g., MySQL), payment gateway API.
Non-functional Requirements
- Performance: System should handle up to 1000 concurrent users.
Integration Testing vs. Regression Testing
- Integration Testing: Tests the interaction between different modules or systems to ensure they work together correctly. Example: Testing if the “Student Registration” module properly interacts with the “Payment Processing” module.
- Regression Testing: Ensures that new code changes do not adversely affect existing functionality. Example: After adding a new “Student Verification” feature, testing whether the existing “Application Review” feature still works as expected.
Gantt Chart for Student Admission System
A Gantt chart for the development of the Student Admission System includes tasks such as:
- Requirement Analysis (2 weeks)
- System Design (3 weeks)
- Development (5 weeks)
- Testing (3 weeks)
- Deployment (2 weeks)
- Maintenance (Ongoing)
Software Metrics
Software metrics are quantitative measures used to assess the quality of software. Common types include:
- Code Complexity: Measures how difficult the code is to understand.
- Lines of Code (LOC): Counts the total number of lines in the codebase.
- Test Coverage: The percentage of the code that is covered by tests.
Test Case for Student Admission System
Testing Technique: Boundary Value Analysis
Test Case: Test the “Student Registration” form to ensure it accepts valid input and rejects invalid input (e.g., age field should only accept values between 18 and 100).
- Input: Age = 17 (Invalid)
- Expected Outcome: “Age must be between 18 and 100.”
IEEE SRS Format for Online Examination System
The IEEE Software Requirements Specification (SRS) format is a structured document that outlines the system requirements. It helps developers and stakeholders understand the system’s functional and non-functional needs.
IEEE SRS Format Sections
- Introduction: Overview of the system, purpose, scope, and assumptions.
- Overall Description: General system characteristics, user needs, and constraints.
- System Features: Detailed functional requirements describing what the system must do.
- External Interfaces: Interaction with other systems, hardware, or software.
- System Attributes: Non-functional requirements like performance, security, and reliability.
- Other Requirements: Additional or domain-specific requirements.
SRS for Online Examination System
Introduction
The Online Examination System (OES) allows students to take exams online, automatically grading their responses and providing feedback.
Assumptions
- The system supports students, examiners, and administrators.
- Students can take online exams, view results, and receive feedback.
- Examiners can create and manage exams.
System Features
- Student Registration: Students create accounts and log in.
- Exam Creation: Examiners can create online exams with multiple question types.
- Question Bank Management: Manage a repository of exam questions.
- Exam Taking: Students can take the exam within a specified time frame.
- Result Generation: After the exam, results are automatically generated and displayed.
External Interfaces
- Hardware: PC, Tablet, Internet Connection.
- Software: Database (e.g., MySQL), Email service for notifications.
Non-functional Requirements
- Performance: Handle up to 1000 concurrent users.
- Security: Encrypt student data and exam responses.
Class Diagram Example
A class diagram is a static structure diagram in UML (Unified Modeling Language) that shows the system’s classes, their attributes, methods, and relationships. It helps in visualizing the objects and their interactions within the system.
Example: In an Online Examination System, the class diagram could have the following classes:
- Student: Attributes – studentID, name, email; Methods – takeExam(), viewResults().
- Exam: Attributes – examID, subject, duration; Methods – startExam(), submitExam().
- Question: Attributes – questionID, questionText, options; Methods – displayQuestion(), evaluateAnswer().
These classes are related by associations (e.g., Student “takes” Exam, Exam “contains” Question).
Data Flow Diagrams (DFDs) for Online Examination System
Level 0 (Context Diagram)
- External Entities: Student, Examiner, Administrator.
- System: Online Examination System.
- Data Flow: Exam Data, Results, Feedback, Exam Registration.
Level 1 DFD
- Student Registration Process: Students submit personal details to create accounts.
- Exam Creation Process: Examiners design and publish exams.
- Exam Taking Process: Students attempt the exam and submit responses.
- Result Generation Process: After submission, the system automatically grades and displays results.
Gantt Chart for Online Examination System
The Gantt chart for the development of the Online Examination System includes tasks such as:
- Requirement Analysis (2 weeks)
- System Design (3 weeks)
- Development (5 weeks)
- Testing (3 weeks)
- Deployment (2 weeks)
- Maintenance (Ongoing)
Acceptance Testing – Alpha and Beta Testing
Acceptance Testing is a type of testing performed to determine whether the software satisfies the acceptance criteria and is ready for release.
- Alpha Testing: Conducted by the development team within the organization to identify bugs before releasing the system to users.
- Beta Testing: Performed by a group of real users outside the organization. It helps identify issues from an end-user perspective before the final release.
Software Maintenance
Software Maintenance refers to the process of modifying and updating software after its initial release to correct faults, improve performance, or adapt to a changed environment. It involves activities such as bug fixing, system updates, and optimization.
Data Dictionary
A data dictionary is a centralized store of data definitions and relationships. This method helps to organize the system around functionality and is useful in systems with well-defined tasks and processes.
Waterfall Model with Feedback
The Waterfall Model is a linear software development process where each phase depends on the deliverables of the previous one. Phases include:
- Requirements Gathering: Define the system’s requirements.
- System Design: Create architecture and system specifications.
- Implementation: Write code according to the design.
- Testing: Verify the system works as expected.
- Deployment: Release the system for use.
- Maintenance: Post-deployment fixes and updates.
Feedback Mechanism
The model allows feedback between phases, particularly during testing and maintenance. For example, if defects are found during testing, the design or implementation phases may need to be revisited.
Short Notes
Structure Chart
A structure chart shows the hierarchical relationship between various system modules, highlighting how sub-functions interact with main functions. It is used in function-oriented design for modularization.
PERT Chart
A Program Evaluation Review Technique (PERT) chart is a project management tool that maps out project tasks, their interdependencies, and timelines, helping identify the critical path for efficient scheduling.
Data Flow Diagrams (DFDs) for Library Information System
Level 0 DFD (Context Diagram)
- External Entities: User (Student/Staff)
- System: Library Management System
- Data Flow: Book Details, User Details, Book Issue/Return Requests.
Level 1 DFD
- Processes:
- Search Books: User searches for books by title/author.
- Issue Book: Issue books to users, update records.
- Return Book: User returns the book, system updates records.
- Manage Users: Register users and update their details.
Identifying Utility Objects in Object-Oriented Design
In Object-Oriented Design, utility objects support other objects by providing reusable functions, such as logging, input validation, or data manipulation. Identifying utility objects involves analyzing common tasks or services needed across multiple components of the system.
Categories of Software Maintenance
- Corrective Maintenance: Fixing defects or bugs in the software.
- Adaptive Maintenance: Updating the software to work in a new environment (e.g., OS upgrade).
- Perfective Maintenance: Enhancing or optimizing the software.
- Preventive Maintenance: Modifying the system to prevent future issues.
Short Notes
Data Dictionary
A centralized repository containing definitions of all data elements, relationships, and structures used within the system.
Coupling
Refers to the degree of dependence between modules. Lower coupling is preferred for system modularity.
Design Approaches
Function-Oriented Design
- Focuses on dividing the system into well-defined functions, which are often represented using Data Flow Diagrams (DFDs) and Structure Charts.
- Example: In a Student Admission System, functions like “Register Student,” “Review Applications,” and “Process Payment” would be the primary components.
Object-Oriented Design
- Emphasizes creating objects that combine both data and behaviors. Objects interact through defined interfaces.
- Example: In a Student Admission System, objects could include `Student`, `Application`, `Administrator`, each with specific methods like `submitApplication()` for `Student` and `reviewApplication()` for `Administrator`.
Waterfall Model vs. Spiral Model
- Waterfall Model: A linear and sequential approach where each phase must be completed before the next starts. It is simple but lacks flexibility for changes during later stages. Example: Developing a Student Admission System in sequential steps—requirements gathering, design, coding, testing, and deployment.
- Spiral Model: An iterative model with risk analysis, allowing for repeated refinement through multiple cycles. It incorporates feedback loops, making it suitable for complex projects. Example: Developing a Student Admission System in phases, revising after each iteration to improve based on feedback.
Data Flow Diagrams (DFDs) for Student Admission System
Level 0 DFD (Context Diagram)
- External Entities: Student, Administrator
- System: Student Admission System
- Data Flow: Application Form, Admission Decision, Payment Information
Level 1 DFD
- Processes:
- Student Registration: Students fill out the application form and upload documents.
- Application Review: Administrator reviews and approves/rejects applications.
- Payment Processing: Payment gateway handles tuition fee payments.
- Report Generation: Admin generates admission and financial reports.
Prototype Model
The Prototype Model involves creating a prototype of the system that allows users to interact with a working version of the system, providing feedback for refinement.
Example: In the development of the “Student Admission System,” a prototype may be created where students can fill out a basic application form. Feedback is gathered, and the prototype is iteratively improved based on user suggestions.
Debugging Strategies
Common debugging strategies include:
- Code Inspection: Manually reviewing code to identify errors.
- Print Statements: Adding print statements to track variable values during execution.
- Automated Debuggers: Using tools that allow step-by-step execution to observe errors.
Reverse Engineering
Reverse Engineering involves analyzing software to extract design and architecture information from the existing codebase, often used for understanding legacy systems or creating documentation for existing systems.
Software Quality – McCall’s Quality Factors
Software Quality refers to how well software meets the defined requirements and user expectations. McCall’s Software Quality Factors focus on key attributes that define the quality of software, such as:
- Reliability: The software’s ability to perform without failure.
- Usability: The ease with which users can interact with the system.
- Efficiency: How well the software utilizes system resources.
- Maintainability: How easily the software can be updated or modified.
- Portability: The ease with which software can be transferred to different environments.
Static Objects in Object-Oriented Design
A static object refers to an object whose properties do not change during the program’s execution. These objects can be used for storing configuration settings or constants.
Example: In an Online Examination System, a static object could be the Exam Configurations class, which stores constants like the maximum exam duration or the passing percentage, which remain unchanged.
System Testing – Recovery and Performance Testing
System Testing is the process of testing the complete and integrated software to ensure that it meets the specified requirements.
- Recovery Testing: Ensures that the system can recover from failures, such as system crashes or network failures. Example: testing if an exam can be resumed after a system crash.
- Performance Testing: Evaluates how the system performs under load. Example: testing how the system performs when 1000 students attempt the exam simultaneously.
Capability Maturity Model (CMM)
CMM is a framework that outlines the process maturity of an organization’s software development practices. It consists of five levels:
- Initial: Ad-hoc and chaotic processes.
- Managed: Basic project management processes are established.
- Defined: Standardized processes are documented.
- Quantitatively Managed: Processes are measured and controlled.
- Optimizing: Focus on continuous improvement.