▁of ▁rules ▁to ▁ensure ▁that ▁each ▁partition ▁is ▁well - defined ▁and ▁clean ▁of ▁kl ud ges , ▁work - ar ounds , ▁short - cut s , ▁or ▁confusing ▁detail ▁and ▁exceptions . ▁As ▁user ▁needs ▁evol ve , ▁( once ▁the ▁system ▁is ▁field ed ▁and ▁in ▁use ), ▁it ▁is ▁a ▁lot ▁easier ▁subsequently ▁to ▁evol ve ▁a ▁simple ▁concept ▁than ▁one ▁l aden ▁with ▁exceptions , ▁special ▁cases , ▁and ▁lots ▁of ▁" f ine ▁print ." ▁ ▁L ayer ing ▁the ▁hardware ▁architecture ▁is ▁important ▁for ▁keeping ▁it ▁sufficiently ▁simple ▁at ▁each ▁layer ▁so ▁that ▁it ▁remains ▁compreh ens ible ▁to ▁a ▁single ▁mind . ▁As ▁layers ▁are ▁asc ended , ▁whole ▁systems ▁at ▁lower ▁layers ▁become ▁simple ▁components ▁at ▁the ▁higher ▁layers , ▁and ▁may ▁disappear ▁altogether ▁at ▁the ▁highest ▁layers . ▁ ▁Accept ance ▁test ▁The ▁accept ance ▁test ▁always ▁remains ▁the ▁principal ▁responsibility ▁of ▁the ▁architect ( s ). ▁ ▁It ▁is ▁the ▁chief ▁means ▁by ▁which ▁the ▁architect ▁will ▁prove ▁to ▁the ▁user ▁that ▁the ▁hardware ▁is ▁as ▁originally ▁planned ▁and ▁that ▁all ▁sub ordinate ▁architect s ▁and ▁engine ers ▁have ▁met ▁their ▁object ives . ▁ ▁Lar ge ▁projects ▁tend ▁to ▁be ▁dynamic , ▁with ▁changes ▁along ▁the ▁way ▁needed ▁by ▁the ▁user ▁( e . g ., ▁as ▁his ▁problems ▁change ), ▁or ▁expected ▁of ▁the ▁user ▁( e . g ., ▁for ▁cost ▁or ▁schedule ▁reasons ). ▁But ▁accept ance ▁tests ▁must ▁be ▁kept ▁current ▁at ▁all ▁times . ▁They ▁are