首页 > 其他分享 >INFO6030 - Systems Analysis and Design

INFO6030 - Systems Analysis and Design

时间:2024-07-31 19:19:14浏览次数:12  
标签:building INFO6030 fire system will Design Systems each your

**INFO** **6030 -** **Systems** ******Analysis** ******and** ******Design**

**Assignment 2 Part B: System D** **esign** ******(30%)**

**Due: 11:59pm Friday 2nd Au** **gust (Week** ******12)**

**Introduction**

The University of Newcastle is replacing its old fire management system for all their buildings. The fire management system is responsible not only for fire detection, but also for managing parts of the early suppression, compartmentation, and evacuation processes of the University’s fire emergency response procedures as well as providing crucial information and control to fire-fighting services on-site. The fire management system (FMS) operates as a hub-and-spoke model, with a central hub managed by the University’s Infrastructure and Facilities Services (IFS). The hub maintains a registry of all buildings operated by the University and connects to the local fire indicator panel (FIP, sometimes also referred to as a Fire Brigade Panel) in each registered building. The hub receives information and alerts from each FIP and can remotely issue commands and configuration updates as required. This is done via the main FIP on campus or via direct access using the IP address of registered equipment on the FMS.

Each building operated by the University has at least one FIP, usually located near the main entrance to the building. Larger buildings may have multiple FIPs located near the main entrances as well in a fire riser, if the building is equipped with one. The FIP takes input from all sensors and alarms located in the building and controls any alert and suppression equipment. Equipment differs depending on how the building is used; for example, rooms containing sensitive electrical equipment are not likely to use a sprinkler suppression system, as this is not ideal for fighting electrical fires. As a further example, food preparation areas such as staff kitchens may not be equipped with smoke detectors, opting instead for a different type of detector such as a heat detector.

Early detection of fires is crucial to an effective response. To that end, each building, and specifically, each detection zone (generally a single room or set of corridors) is equipped with detection equipment, both automated and manually triggered. This includes but is not limited to smoke detectors, heat detectors, carbon monoxide detectors, manual pull alarms, and manual break glass alarms. In some cases, a single zone may contain multiple detectors, particularly where a high rate of false alarms is likely to occur. As an example, a zone where smoke is frequently detected may still use a smoke detector, but the FIP maybe programmed with a rule that will, when the detector is triggered, query a different detector in the same zone, such as a heat detector, and only enter an alarm state if the heat detector detects a temperature above a certain level.

When a fire is detected, the FIP will follow rules set by IFS, that, depending on the severity of the fire detected, may involve triggering suppression systems, evacuation, automatically contacting firefighters, and compartmentation systems. Suppression systems vary depending on how the zone is used, but may include sprinklers, gas suppression, foam suppression, and dry chemical suppression. A small fire detected in a small room with equipped sprinklers does not for example, necessarily require the entire building to be evacuated immediately. The FIP might be configured with a rule to first activate the sprinklers in the room, only triggering an evacuation if the detectors in the zone show the fire becoming worse after a set amount of time. The FIP can also shutoff building power, which maybe necessary in some cases to remove a source of ignition for additional fires.

If, however an evacuation is necessary, triggered either by an automated rule, manually from the FIP or remotely from the hub,then the FIP may trigger warning systems in the building, such as sirens and strobe lights, such as from an occupant warning system and/or emergency warning and intercommunication system. The FIP may also detect conditions such as a power outage, or a high level of smoke in corridors and activate additional emergency lighting, or control dynamic emergency exit signs to activate their alarm modes with inbuilt speakers to guide people towards them, or in case an escape route is compromised, switch these signs into warning mode to alert people to seek an alternative exit. Note that not all emergency exit signs have these dynamic features included, some, including older models, may indeed not even be powered at all. As a fire grows worse, it maybe necessary to attempt compartmentation of the fire. The FIP can be used to perform. this task either automatically or manually, by closing fire doors, fire windows, and fire shutters within the building to delay the spread of a fire, allowing people additional time to escape. Fire doors are located at points within a building where fire resistant materials have been used in the construction of the building, and sub-divide the building into smaller sections that are typically easier for firefighters to manage.

The FIP, in addition to its automated functions, also includes an adjacent master emergency control panel in the same cabinet with indicator lights and buttons that allow authorised personnel and firefighters to quickly see the state of all connected sensors and systems, and to manually trigger or override them. It can also be used to send an all-clear signal to the system once the building is safe tore-enter, which will silence any alarms, reset detectors, and shut-off any active suppression systems. Any alerts are sent to the hub, which stores a record of any alarms, detectors triggered, suppression systems turned on, fire doors closed, firefighters contacted etc. Authorised IFS managers can generate reports of these records, which can be customized according to several parameters, for example, a list of the most frequent detectors triggered regardless of whether an alarm condition was entered (this is often used for identifying common culprits for false alarms). Another example would be a list of all recently activated suppression systems, and the amount of time they were activated for (this can be used to calculate how much water/chemical agent/foam/etc has been used and needs to be ordered to restock the relevant suppression systems).

Each building has at least one member of staff assigned to the role of evacuation warden for the building. The hub must alert these person/persons if an evacuation is triggered. Evacuation wardens can also manually trigger a building evacuation at anytime. The current state of building alarms and equipment across campus are visible from the main FIP on the FMS network. To ensure that everyone can be accounted for, each building entrance is to be fitted with dual gait and facial recognition linked to the University database. If someone cannot be recognised, they should be listed as an unidentified occupant.

The current building occupancy list will be stored in the hub and made available to the evacuation wardens of the building, as well as authorised IFS staff.

The hub can also send commands and configuration updates to the local FIP of each building. There are  many possible ways that this could be used, for example, to trigger an evacuation of every building for a fire drill, to update the automated rules for a single building, to update the automated rules in every building for a certain type of equipment, to manually trigger compartmentation in a building if the local FIP cannot be accessed in a fire, to initiate system tests during an inspection, etc. For auditing purposes, any such use of the hub must be recorded and stored. Managers can generate reports of these records.

Where commands are in conflict, the mostrecent command must take precedence; for example, the hub might send a remote command to close a fire door, but a person trapped in the building can still use the  local FIP to temporarily open the door so that they can escape.

Both local building FIPs as well as the hub can be used to override building security systems. Areas that are usually locked by key or that require a University swipe-card to enter can be remotely unlocked in an emergency either in a single building from the local FIP or anywhere in the University from the hub. Use  of this function must also be recorded for auditing purposes. It maybe assumed that firefighters have their own unique code pre-programmed into every FIP that can be used to access all functionality. Additional codes to access some or all functions of an FIP, or multiple FIPs across a set of buildings maybe added by IFS, either from the hub, or from the local FIP. Where added locally, the FIP will send this information back to the hub to prevent data conflict. The hub can communicate with the separate University security system for this purpose. The security system has a general override code associated with the fire management system as a whole that is used whenever the fire management system needs to override the  security system. It is for this reason that the fire management system has the responsibility of associating use of this code with a specific user, or external firefighters (nominally this would be Fire and Rescue NSW) for auditing purposes.

The hub maintains all records, such as a list of buildings, equipment, configuration settings, users and their permission levels, alarms, overrides, etc. These records need to be easily searchable by IFS managers and   auditors. Additional requirements for the FMS and other interconnected systems are available at

https://www.newcastle.edu.au/__data/assets/pdf_file/0010/937639/UON-Fire-Services-Guiding-

Principles-V1.3.pdf. Note that the scope of this project is restricted to the master control (hub) of the FMS, as other equipment comes from external suppliers according to defined standards.

**Objective** ******of** ******the** ******system**

The main objective is to develop an online management system for IFS that will control the hub of the fire management system. The local building FIPs are produced by other companies, but the hub needs to be able to communicate with them using their published addressable interface (IP address on the fibre FMS).

1.   The manager needs all information at their fingertips to make decisions.

2.   Safety is a critical aspect of this system, as failure could result in loss of life where a fire occurs.

3.   The manager requires multiple types of reports, periodic each month, on-demand, and after-action reports (automatically generated after a major alarm state has been resolved).

4.    Records must be kept secure, only accessed by authorised staff.

5.   The system must be able to receive and report on equipment and sensor data as it comes in, that is,it must be ‘live’ 24/7, with reliability and uptime a priority.

The system should be online, so that, for example, IFS staff can issue commands from a mobile app outside a building in an emergency, instead of having to run to an accessible computer and login, although this should  also be possible.

**Tasks**

The system definition above will be used for the two assignments for this course. For this assignment, you will partially design and propose an implementation strategy for the system. You should identify system components and realize system requirements. In this assignment you will design the system according to the requirements identified in part A, map business rules to your design and construct a model of the system in   UML. Specifically,you will develop sequence diagrams, interface storyboards, test plans, risk mitigation plans, and map out a class diagram for the solution domain.

There are no limits to how far the design and implementation might go. However, complexity, coverage and correctness of the elements will betaken into account in the assessment of the submitted work.

The main deliverable of this assignment is a report and Gantt Chart to be submitted via Canvas,

*Note,* **your academic may also ask for a hard copy of the report and for your team to show your Gantt file in class.

For the report, you need to submit a Word or PDF document and a Gantt file in *one* ***compressed* ***(zip)file* **containing the following:

**1.** ******Report cover sheet containing** ******the**

a.   Default is 5 Team members (first and lastname and student numbers)

b.   Lab Day

c.   Lab Room,

d.   Lab Time and

e.   Lab academic (first name only)

**2.** ******Introduction to the report (2.5** **Marks)**

a.   What is in the report?

b.   Who is the intended audience of this report?

c.   What are the objectives of this report?

d.   How does each element of this report contribute to achieving the report objectives?

e.  https://www.monash.edu/rlo/assignment-samples/engineering/eng-writing-technical- reports/introduction

3.   **Business Rules (10 Marks)**

a.   Refine business rules which you have already identified in Assignment 1 Part A. You may add on/ update your business rules as you discover more detailed requirements (as you perform iterative modelling). Your final list of business rules cannot be smaller than the requirements for part A.

b.   Explain how each business rule is captured (enforced) by your team design. This is an

important part of testing your design. Remember some business rule may only be captured by human business processes. So is a business rule captured by an interface, by class data or a method etc?

c.   Use the following table format for this process

| Business Rule                | System Mapping                                         | Organisational Mapping                                                                          |
| ---------------------------- | ------------------------------------------------------ | ----------------------------------------------------------------------------------------------- |
| B1: Customer contact details | Data collected in the customer class and the interface | Manager notified if data is   not complete by the system (not all BR will require this section) |

**4.** ******System Design (30 Marks)**

a.   The complete subsystem specification for the system.

i.   You will need to identify the subsystems, and describe the services they each

provide. (see Brugge and Dutoit Chap 6 Fig 6-29): Discussed in lecture 8 (see week

8 lab notes page 3: Fig 6-29)

  


ii.   Illustrate the relationships between each subsystem: Discussed in lecture 8 (see week 8 lab notes)

b.   A class diagram with all classes to be implemented (including the **B** **oundary** ****classes, **Controller** classes and **Entity** classes) and appropriate relationships between them.

c.   All attributes for each class. Include access modifiers i.e. private, public and protected for each attribute of the classes that are required for each Use Case: Discussed in lecture 7

d.   All operations/ methods, include access modifiers i.e.  private, public and protected for each. You should also include input parameters and return types for each method.

e.   Your class diagram should follow principles of good system and object design as taught in lectures. Include a description explaining your design and the decisions you made.

**5.   Use** ******Case Mapping** ******to** ******Sequenc** **e Diagram** ******(20** ******Marks)**

a.   Each team member will revise their **Use Case description** from assignment Part A (unless otherwise assigned by your academic) e.g. cannot use the logon use case.

b.   Each team member will **create** ******a** ******subset** ******of** ******the** ******class** ******di** **agram** ****(section 4) that shows only

the part of the system required to implement their Use Case description: Discussed in lecture 7

c.   Each team member will **create a sequen** **ce diagram** ****(for the Use Case) that shows the   relevant Boundary, Controller and Entity classes from your class diagram in section 5b.

d.   Give a short description for each diagram to briefly explain the interactions among the models to perform. the use case.

**6.** ******User Interface (10 Marks)**

a.   Each team member will develop a user **interfaces (i.e. screen design)** ****using your use case description, subset of the class diagram and sequence diagram (section 5) as the basis of your interface (The logon interface is not to be modeled).

b.   Use the storyboarding technique (eg Powerpoint) to illustrate each screen required by your use case,including alternate flows, and exceptions.

c.   Each interface (team style) must be consistent in appearance and visual style.

d.   Consider each user of your interface, considering accessibility and ease of use.

**7.** ******Test Plan (5** ******Marks)**

a.   You are required to propose a testing strategy for the system, as well as any future

modifications to the system. Your strategy should include different levels of tests:

i.   Unit tests, Integration tests, System tests, and User Acceptance tests.

ii.   For each level provide two example of white-box and two example of black-box  testing (aside from User Acceptance tests, which will only have black-box tests).

iii.   Your test plan requires test cases, sample inputs, and expected outputs. Provide

examples of possible defects to illustrate how your proposed testing strategy could identify a variety of faults.

**8.** ******Risk Assessment (5 marks)**

a.   Identify a list and ranking of major and minor risks for the project.

b.   Rate the likelihood and impact of each risk to determine their severity.

c.   Risks with a high severity should include a mitigation strategy, and an updated rating before/after the strategy is implemented.

d.   To help with this you might like to consider questions such as: 

i.   What is a risk matrix?

ii.   What use cases involve risk?

iii.   Are there any ethical considerations that will need to be considered - If so, what are they?

iv.   Are there any special privacy or security conditions expected by the client?

v.   The risks will include the project and your team (e.g. cost and schedule overruns).

**9.** ******Deployment (5 Marks)**

a.   What is your team proposing for a deployment strategy?

i.   How will you address issues in data migration from the old system to the new system?

ii.   How will you handle user training?

iii.   How does your chosen strategy address the potential for system faults and bugs? b.   Will you use a direct, pilot, parallel, or phased deployment (or a hybrid approach)?

i.   Justify your choice in comparison to the alternatives.

ii.   What are some potential disadvantages to your choice and how will these be mitigated?

c.   Have a look at the 14-2-Deployment.mp4 video link.

d.   Give an example (with inline citations and references) of a real-world situation where a similar strategy was used to support your argument.

**10.** ******Team Management (10 Marks)**

a.   Meeting notes for at least 5 meetings and MS teams activity report

b.   Gantt Chart (MS Project)

i.   Your team will continue to refine your existing chart and show who has done what and the percentage completed for each task

ii.   This part of your assessment will be utilised if there is any issue with team

management of production and team submission. Makes sure you keep copies of your individual work

c.    Self and Peer-Assessment process using TeamMates (5 marks individual, after team submission)

**11.** ******Conclusion (2.5 Marks)**

a.   What was completed

b.   What was not completed and why

c.   How did each section of the report achieve the report objectives?

d.   What are your recommendations for the client?

e.  https://www.monash.edu/rlo/assignment-samples/engineering/eng-writing-technical- reports/conclusions-and-recommendations

12. **Reference list** (including but not limited to, any references used for the introduction and business rules sections in particular)

**Total** ******100 marks Final mark** ******out** ******of** ******30.**

*Self* ***and Peer* ***Assessment:* **All team members will be individually required to complete a Self and Peer

Assessment (see section 9c) within a week after the due date, this is an opportunity to reflect on how well your group performed and consider areas of improvement for future group work. The results of this

assessment may be used to adjust the marks of individual members of the group where it is considered that a group member has significantly underperformed.

You will receive an email following the due date containing a link to the self and peer assessment. You will  be asked to rate your own performance as well as the performance of each member of your team and give

a brief comment justifying your ratings (this will be anonymous, only staff will see who gave each

comment). Along with your assignment feedback, you will receive the anonymous comments from your  teammates, as well as two scores: RPF (Relative Performance Factor), which is an indication of how your teammates have rated you compared to the team average; and SAPA (Self-Assessment to Peer

Assessment), an indication of how you have rated yourself compared to how your teammates have rated you.

 

标签:building,INFO6030,fire,system,will,Design,Systems,each,your
From: https://www.cnblogs.com/vx-codehelp/p/18335275

相关文章

  • 【原创教程】Microsoft Designer AI绘图进阶教程:第3部分
    在第2部分当中,介绍了基础的Designer操作。那么这一个部分将会介绍一些高级的概念和操作方法。1、隐式提示词(Suggestiveprompts)隐式提示词指的是通过给出一个提示词,而起到同时给出多个提示词的作用。所以它也可以被称之为暗示。我给这个术语制定的英译就带有暗示的意思:Suggest......
  • DDD(Domain-Driven Design)领域驱动设计
    在软件开发中,DDD(Domain-DrivenDesign,领域驱动设计)是一种方法论,它强调在开发过程中将业务领域的知识和规则作为核心。DDD的目标是通过理解和建模业务领域来创建更好的软件系统。本文将详细讲解DDD的基本概念、原则和实践方法。什么是DDD?DDD是一种软件设计方法,它专注于理解......
  • vite5-macos仿macOS网页osx管理系统|vue3+arcoDesign桌面os
    基于vite5.x+vue3+arco-design原创自研网页版os管理框架ViteWebOS。使用最新前端技术vite5+vue3+pinia2+arcoDesign+sortablejs+echarts搭建网页pc版桌面os式后台管理系统解决方案。支持自定义桌面栅格布局引擎、可拖拽桌面图标、多屏分页管理、自定义桌面壁纸主题、毛玻......
  • Vue3-WebOS网页版os系统|vite5+pinia2+arco-design仿macOS桌面os管理
    原创Vue3+Pinia2+ArcoDesign仿macOS桌面网页版os管理系统ViteMacOS。vite5-vue3-macos基于最新前端技术vite5.x+vue3+pinia2+arco.design+sortablejs+echarts构建网页版osx后台管理系统新解决方案。支持windows+macos两种桌面模式、自定义桌面栅格布局引擎、可拖拽式桌面菜单/程......
  • Substance designer常用节点介绍
    RGBASplitRGBAMerge——分离四通道,合并四通道Distance——SDF,扩大图片像素HistogramScan——类似于smoothstep,硬化或模糊边缘Bevel——Distance只能扩大,但是这个可以缩小和扩大InvertGrayscale—— 反转Transformation2D—— 开放手动调整缩放之类的参数EdgeDe......
  • Modelsim仿真时报错Error (vlog-7) Failed to open design unit file XXXXX in read m
    根据之前遇到的问题Vivado关联Modelsim仿真时一直卡在Executinganalysisandcompilationstep…的解决我在TclConsole窗口查看出现的Error信息。出现报错:Error:(vlog-7)Failedtoopendesignunitfile“XXXXX”inreadmode查阅网上解决办法VivadoError:(vlog-......
  • vue3 + arco design vue 表身单元格合并
    表格展示效果如下图:后端返回的数据格式如下arcodesignvue单元格合并还挺复杂的,今天接到这个需求时,还是有点无从下手,后来经过一些列尝试之后得出如下代码<a-tableclass="table-data":data="tableData":bordered="{wrapper:true,cell:true}":span-method="dat......
  • powerdesigner导出图片&PDF
    1、导出图片1.1CTR+A选中当前页的设计的表(物理模型或概念模型设计的表都可以)1.2、edit-->exportImage1.3选择自己要保存的图片类型:png/JEPG/SVG等等关于导出来的图片的清晰度,这里要说一下,自己保存的png和jepg都比较模糊,SVG虽然清晰度很高,但是手机上却无法查看,因此又研......
  • Python - Adob​​e InDesign Javascript 脚本帮助从 Python 调用 JSX
    提前致谢。希望每个人都表现出色。我试图从python调用Adob​​eIndesignJSX文件,下面是示例代码:我想在Adob​​eINdesign2024或更高版本上运行它。我在PythonInDesign脚本编写上看到了一些示例:从预检中获取溢出文本框以自动调整大小作为参考,可能适用于Ado......
  • DevExpress中文教程 - 如何在.NET MAUI应用中实现Material Design 3?
    DevExpress .NETMAUI多平台应用UI组件库提供了用于Android和iOS移动开发的高性能UI组件,该组件库包括数据网格、图表、调度程序、数据编辑器、CollectionView和选项卡组件等。获取DevExpressv24.1正式版下载DevExpress技术交流群10:532598169      欢迎一起进群讨论Mate......