Jump to content

Structural design processes: Difference between revisions

Structural design processes (view source)

Revision as of 21:27, 19 November 2021

741 bytes added ,  21:27, 19 November 2021
no edit summary
No edit summary
No edit summary
Line 57: Line 57:
When assigning a task, take account of (a) the competence of the person who is to carry out the task and (b) the need to train people to do the task.
When assigning a task, take account of (a) the competence of the person who is to carry out the task and (b) the need to train people to do the task.
====Reviews====
====Reviews====
Regular review meetings should be included in the schedule to address
''Regular review meetings'' should be included in the schedule to address:
*Progress in relation to the plan
*Progress in relation to the programme.
*Progress in relation to meeting the [https://eit.engineers.scot/index.php?title=Top-down_strategy#Requirements requirements]
*Progress in relation to meeting the [https://eit.engineers.scot/index.php?title=Top-down_strategy#Requirements requirements]
''Milestone reviews''  Two major reviews in the design plan are:
# At the end of the concept stage the state of the design is reviewed to ensure that what is proposed has the potential to satisfy the requirements i.e. that the design is valid.  This results in a Design Proposal for agreement by the client.
# The final review assessesm the outcomes against the requirements.


=== Review and revise ===
=== Review and revise ===
Line 66: Line 70:
Key reflective questions are:
Key reflective questions are:


* ''Validation'': Is the process being used suited to the context?
* ''Validation'': Is the process suited to the context?
* ''Verification'':  Has the process been correctly implemented?
* ''Verification'':  Has the process been correctly implemented?


=== Control strategies ===
.It is important to use strategies that will 
==== Requirements conformance ====
'''General'''
* Be vigilant throughout the design process about requirements conformance
* At design review meetings have requirements conformance on the agenda.
'''Actions'''
* Define the requirements at Stage 1.  The requirements at this stage should be independent of the type of structure.
* Modify the requirements at Stage 2 taking account of decisions made at that stage.
* Seek to avoid changes to the requirements after stage 2.
'''Validation of the requirements:'''
Seek to ensure that:
* all requirements been identified
* all requirements been adequately stated in the Structural Design Brief
'''Verification'''
* Ensure that the mandatory requirements have been satisfied  
* Explain why any non-mandatory requirements have not been fully implemented.
==== '''Analysis modelling''' ====
Use the strategies recommended in this document.
==== '''Code of practice conformance''' ====
'''Validation of code provisions'''
Ensure that the design context is within the scope of the codes that are specified in the Structural Design Brief. If it is not, seek to ensure that relevant issues that are not covered in the codes are addressed. This is especially important in innovative contexts. See, for example, the [[Structural design failures|Ronan Point Collapse]]
'''Performing the calculations'''
Code of practice rules should be processed using software that has been subject to rigorous QA assessment.
Hand calculators should only be used in preliminary work and back-of-an-envelope checks. They should not be used for final calculations because of the increased risk of errors when values are being keyed-in.
See guidance on programming of calculations.


'''Input checking'''


Throughout the design process it is especially important to focus on the [[Top-down strategy|requirements]] - to ensure that all requirements have been identified and are adequately addressed in the design. For examples of the use of requirements see  [[Structural design of a footbridge|Footbridge]]. The reasons for structural failures can often be led back to faults in requirements -  see, for example, the following case studies:  Tay Rail Bridge Disaster, Ronan Point Collapse, Florida Bridge Failure, Hartford Civic Center Collapse. Processes for identifying requirements and for ensuring that they are addressed need to be used.
Verify input to software


Review actiities include:
'''Results transfer'''


* '''Constant review activity''' Throughout the design process, there should be continual assessment of the inputs, the processes and the outputs  - see Figure 4.  This involves asking questions such as: Are important issues being missed?  Should I seek advice about this? Has this been properly assessed? Such questions need to answered and action taken when appropriate.
Verify that the results have been correctly transferred to drawings and schedules,
* '''Design reviews''' The design programme should include a schedule of formal meetings of the design team to review (a) progress and (b) the satisfaction of requirements.
* '''Milestone reviews ''' The two major reviews in the design plan are:


# At the end of the concept stage the state of the design is reviewed to ensure that what is proposed has the potential to satisfy the requirements i.e. that the design is valid.  This results in a Design Proposal for agreement by the client..
=== Inception Stage ===
# The final review verifies that the design will satisfy the requirements.
Retrieved from ‘https://eit.engineers.scot/index.php/Special:MobileDiff/1338’