compruteru/snhu_cs230_design_journal

SNHU CS230 Software Design Journal for client The Gaming Room

SNHU_CS230_Design_Journal

Southern New Hampshire University CS-230 Software Design Journal for client The Gaming Room

The Gaming Room, "Draw It or Lose It"

Software Design Document

• The Gaming Room was seeking developers to port their existing game, Draw It or Lose It, available on Android, as a web-based game to serve multiple platforms, where cross-platform compatibility for each of the three mainstream operating systems and browsers were tested, with an IOS app which was also developed. Specific requirements included:

  • A game will have the ability to have one or more teams involved.
  • Each team will have multiple players assigned to it.
  • Game and team names must be unique to allow users to check whether a name is in use when choosing a team name.
  • Only one instance of the game can exist in memory at any given time. This can be accomplished by creating unique identifiers for each instance of a game, team, or player.

• The software design document showcased to the client an easy to digest roadmap for the actionable items and constraints in porting the application, the design patterns used to solve the game function and operation, as well as described which platform, architecture, and operating system characteristics and expectations were realized in choosing certain implementations. Platform recommendations were advised, with the design documentation updated to reflect the best option for their needs, while following best practices.

• Having design patterns identified allowed for a seamless integration of the functional requirements into program language. With the UML and documentation available, programming time was optimized to reduce errors and troubleshooting, where not only having the reference, but simply working through the structure of constraints and requirements help to directly align the client needs with lines-of-code.

• This was my attempt at clarifying requirements and constraints to the client, which If I could go back to revise the document, I would create more structure and higher-level outline throughout some of the sections for conciseness in imparting the pertinent information. Largely I think simplicity and relatability are concerns while imparting technical information to an audience who know what they need but know they will accomplish this by hiring a team of professionals, so removing the technical comprehension barrier is of utmost importance, all the while making sure to highlight where constraints and requirements are met, while highlighting benefits and savings in making the right choices.

• Largely I think simplicity and relatability are concerns while imparting technical information to an audience who know what they need but know they will accomplish this by hiring a team of professionals, so removing the technical comprehension barrier is of utmost importance, all the while making sure to highlight where constraints and requirements are met, while highlighting benefits and savings in making the right choices.

• First was identifying user requirements, keeping in mind constraints, identifying design patterns which best upheld their needs, while maintaining current best development practices, and efficiently coordinating the strengths and weaknesses in choosing specific architectural characteristics. In future strategies I plan to utilize a wide-ranging information gathering strategy to include more demographic of the intended application audience (specifically, the technological modalities, fingerprints, and preferences therein through which they access the application), to better predict and recommend specific choices regarding certain elements of a comprehensive system. Depending on use cases, it may be advisable to perform hybrid-cloud, full-premise, or full-cloud; having tell-tales in-sight will allow for future implementations to be constructed just as seamlessly.