Assignment 4: Term Paper Due Week 10 And Worth 200 Points

Assignment 4: Term Paper Due Week 10 and worth 200 points You were talking to members

You were talking to members of your favorite local band after a recent show. The topic of software came up, and the leader said she has a love-hate relationship with it. She loves the recording software they use and is okay with QuickBooks for the band's financial records. But, she does not like the available options to track bookings and create set lists that draw from their entire repertoire. In addition to their regular weekly gigs, the band performs for many school assemblies and community events.

They have to pick music that's appropriate for the audience and the theme without being repetitive. They are constantly adding new songs to their catalog, and putting others on hiatus. The band likes to take requests, so they frequently update the set list after a gig. The band does not want to bother entering chords or lyrics because they don't use computers or phones on stage. You offer to put together a system design to address the band's needs.

It's okay to collect ideas by looking at off-the-shelf solutions, but the design must be your own for this assignment. Include the following in your design:

1. A list and short explanation of each function to manage: the band's song catalog, bookings, set lists, and any other category you believe is important for this application.
2. A logical data design that supports all of these functions. Use either an entity-relationship or a UML class diagram, which should be in third normal form. Indicate all primary keys, relationships, and cardinalities.
3. Recommend a system architecture that identifies the hardware and software components and how they interact. Include a short (not more than 500 words) description and rationale. Illustrate using your choice of a static functional decomposition or object-oriented diagram.
4. Identify security concerns and other nonfunctional requirements for this system.
5. Propose at least three distinct and measurable criteria to evaluate the quality of the finished software.

Important Note: The required attached template must be used for this assignment and is not optional. It has been designed so that papers are logically organized and includes prompts for all required information for the assignment. Assignments submitted not using this template will be returned ungraded and must be resubmitted using the template. Late penalties on improperly submitted papers will apply in accordance with the published late policy.

Paper For Above instruction

Introduction

The modern digital era provides an array of tools to manage various aspects of a band's operations, including song catalogs, bookings, and set lists. For a community-oriented band with diverse performance requirements and frequent updates, an integrated, user-friendly, and secure system becomes essential. This paper presents a comprehensive system design tailored to meet the band's specific needs, focusing on core functionalities, data modeling, system architecture, security concerns, and quality assessment criteria.

Functional Requirements

1. Song Catalog Management

This function allows the band to maintain an up-to-date database of all songs. It includes adding new songs, updating existing entries, sidelining songs, and deleting obsolete ones. Attributes should include song title, artist, genre, key, tempo, and availability status. The system should enable efficient retrieval for set list creation and updates without requiring on-stage chord or lyric entry.

2. Booking Management

This functionality tracks upcoming gigs, venues, dates, times, and client details. It supports booking creation, modification, and cancellation, with reminders for upcoming events. It should also record performance details like duration and special requirements.

3. Set List Management

The set list module allows musicians to select, organize, and modify performance sequences drawn from the catalog. It must support multiple set lists per event, facilitate reordering, add or remove songs efficiently, and incorporate audience requests post-performance.

4. Additional Features

Other essential functions include a song request interface for audiences, a catalog update log, and reporting features for gig summaries and song popularity. The system should be intuitive to reduce on-stage entry and facilitate rapid updates post-performance.

Logical Data Design

The data model employs an Entity-Relationship diagram, normalized to third normal form, to support all functional modules.

The key entities include:

• Song: SongID (PK), Title, Artist, Genre, Key, Tempo, Status
• Booking: BookingID (PK), Date, Venue, ClientName, Duration, SpecialRequirements
• SetList: SetListID (PK), EventID, SongOrder
• SongInSetList: SetListID (FK), SongID (FK), SequenceNumber

Relationships indicate that a Song can appear in many SetLists, and each SetList consists of multiple Songs, establishing a many-to-many relationship via the SongInSetList associative entity. Each Booking can include multiple set lists or performance plans, coordinated through the EventID linkage. Primary keys are clearly marked, with foreign keys establishing relationships and cardinalities reflecting one-to-many or many-to-many associations as appropriate.

System Architecture

The system adopts a client-server architecture utilizing a web application interface for ease of access and updates. Hardware components include servers hosting a relational database management system (RDBMS), application servers running business logic, and client devices such as laptops or tablets. Software components feature a web server (e.g., Apache or Nginx), backend application logic developed with supported frameworks (e.g., Django, Flask, or Node.js), and a relational database (e.g., MySQL or PostgreSQL).

The interaction flow involves clients accessing the user interface via secure web browsers, submitting requests that the backend processes and stores in the database, which in turn supplies data for display or updates. This setup supports remote access during gigs and post-event updates, ensuring flexibility and real-time data integrity.

A static functional decomposition diagram visualizes the modular structure, highlighting core modules such as user interface layer, business logic, data access layer, and security/authentication controls. The rationale centers on scalability, ease of maintenance, and security, enabling the band to adapt and expand the system as needed.

Security Concerns and Nonfunctional Requirements

Privacy and data security are paramount; access controls should authenticate users and restrict data modifications based on roles, preventing unauthorized changes. Data encryption during transmission and at rest safeguards sensitive information. The system must also incorporate regular backups, audit trails, and protection against common vulnerabilities like SQL injection.

Nonfunctional requirements include system availability (aiming for 99.9% uptime), usability with a user-friendly interface, responsiveness ensuring updates occur with minimal latency, and scalability to accommodate additional features or user load. Reliability constraints specify continuous operation during performance reviews and live gigs, while maintainability demands modular code for straightforward updates and troubleshooting.

Quality Evaluation Criteria

1. Usability: The system should allow users to perform updates, searches, and modifications within five clicks or less, confirmed through user testing and feedback surveys.
2. Performance: Response times for data retrieval should be under two seconds for typical queries, measured through system benchmarking under simulated load conditions.
3. Security: The system must pass penetration testing, ensuring no vulnerabilities exist for manipulation or data breaches, verified through regular security audits.

Conclusion

Designing a tailored management system for the band addresses their operational needs by enabling efficient catalog, booking, and set list management, while safeguarding data integrity and security. A well-structured data model, scalable architecture, and clearly defined nonfunctional requirements ensure the solution is robust and adaptable, supporting the band's evolving repertoire and performance schedule. While off-the-shelf tools can inspire, a custom-designed system guarantees alignment with their specific workflows, facilitating smoother performances and better audience engagement in community events and gigs.

References

• Elmasri, R., & Navathe, S. B. (2015). Fundamentals of Database Systems (7th ed.). Pearson.
• Larman, C. (2004). Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development. Prentice Hall.
• Shaw, M., & Garlan, D. (1996). Software Architecture: Perspectives on an Emerging Discipline. Prentice Hall.
• Pressman, R. S. (2014). Software Engineering: A Practitioner's Approach (8th ed.). McGraw-Hill Education.
• Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley.
• Hoffer, J. A., Venkataraman, R., & Topi, H. (2016). Modern Database Management (12th ed.). Pearson.
• Booch, G. (2006). Object-Oriented Analysis and Design with Applications. Addison-Wesley.
• Hastie, T., Tibshirani, R., & Friedman, J. (2009). The Elements of Statistical Learning. Springer.
• Nielsen, J. (1994). Usability Engineering. Morgan Kaufmann.
• ISO/IEC 25010:2011. (2011). S systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models. International Organization for Standardization.