Arsitektur Pemrograman oleh Edith Cherry, FAIA, ASLA dan John Petronis, AIA, AICP Update terakhir: 2009/09/02 Dalam Halaman Ini Pengantar Deskripsi Muncul Isu Relevan Kode dan Standar Mayor Sumber Daya Pengantar Arsitektur pemrograman dimulai ketika arsitektur mulai. Struktur selalu berdasarkan program: keputusan dibuat, ada sesuatu yang dirancang, dibangun dan ditempati. Di satu sisi, arkeolog menggali bangunan untuk mencoba untuk menentukan program-program mereka. Hari ini, kita mendefinisikan pemrograman arsitektur sebagai proses penelitian dan pengambilan keputusan yang mengidentifikasi ruang lingkup pekerjaan yang harus dirancang. Sinonim termasuk "pemrograman fasilitas," "persyaratan fungsional dan operasional," dan "pelingkupan." Pada awal 1960an, William Peña, John Focke, dan Bill Caudill dari Caudill, Rowlett, dan Scott (CRS) mengembangkan suatu proses untuk mengatur upaya pemrograman. Pekerjaan mereka didokumentasikan dalam Soal Mencari, teks yang dipandu arsitek dan klien banyak yang berusaha untuk mengidentifikasi lingkup masalah desain sebelum awal desain, yang dimaksudkan untuk memecahkan masalah. Pada 1980-an dan 1990-an, beberapa sekolah arsitektur m ulai turun pemrograman arsitektur dari kurikulum mereka. Penekanan dari agenda Post-Modern dan Dekonstruksi adalah bukan pada bentukkeputusan. Pemrograman dan perhatian te rhadap pengguna bangunan bukanlah prioritas. Sekarang, beberapa generasi arsitek sedikit keakraban dengan pemrograman ar sitektur dan keuntungan yang ditawarkan: Keterlibatan pihak yang berkepentingan dalam definisi lingkup ke rja sebelum usaha desain Penekanan pada pengumpulan dan menganalisis data awal pr oses sehingga desain didasarkan pada keputusan suara Efisiensi yang didapat dengan menghindari desain ulang dan mendesain ulang lebih sebagai persyaratan muncul selama desain arsitektur. Non-dimensi grafik yang menggambarkan peluang untuk biaya vs pengaruh perubahan Waktu yang paling efektif-biaya untuk membuat perubahan yang selama pemrograman. Ini fase dari
proyek adalah waktu terbaik bagi pihak yang berkepentingan untuk mempengaruhi hasil proyek. "Bangunan utuh" pendekatan desain ini dimaksudkan "untuk membuat sebuah bangunan tinggi kinerja yang sukses." Untuk mencapai tujuan itu, kita harus menerapkan pendekatan desain terpadu untuk proyek selama fase perencanaan dan pemrograman. Orang yang terlibat dalam desain bangunan harus berinteraksi erat sepanjang proses desain. Pemilik, penghuni bangunan, dan operasi dan personil pemeliharaan harus terlibat untuk memberikan kontribusi pemahaman mereka tentang bagaimana bangunan dan sistem yang akan bekerja untuk mereka sete lah mereka menempatinya. Tantangan mendasar dari desain "seluruh bangunan" adalah untuk memahami bahwa semua sistem bangunan saling bergantung. (Sumber: WBDG situs Web, tujuan dari desain "Seluruh Bangunan"). Kembali ke atas Deskripsi Menurut perjanjian AIA standar, pemrograman adalah tanggung jawab pemilik. Namun, arah programatik pemilik dapat bervariasi dari samar untuk sangat spesifik. Dalam beberapa kasus, pemilik tidak memiliki keahlian untuk mengembangkan program dan harus menggunakan jasa seorang konsultan program. Konsultan pemrograman yang paling baik arsitek atau pelatihan arsitektur, tetapi yang lain telah menjadi terampil melalui pengalaman. Banyak arsitek melakukan pemrograman sebagai layanan tambahan untuk kontrak standar mere ka. Konsultan banyak jenis bangunan (laboratorium, perawatan kesehatan, teater, dll) memiliki keahlian dalam pemrograman komponen fasilitas. Tingkat Pemrograman Pemrograman mungkin terjadi untuk tujuan yang berbeda dan dapat mempengaruhi tingkat detail penyelidikan dan kiriman. Sebagai contoh, pemrograman di tingkat perencanaan master lebih strategis di alam-memberikan informasi kepada pemilik bangunan untuk membuat keputusan mengenai kebutuhan ruang saat ini dan proyeksi dan penganggaran kasar untuk implementasi. Pemrograman pada tingkat proyek individu menyediakan tertentu, informasi rinci untuk memandu desain bangunan. Sebuah Proses Arsitektur Pemrograman Pembahasan berikut ini dimaksudkan untuk menyediakan proses yang jelas untuk melakukan penelitian dan pengambilan keputusan yang mendefinisikan ruang lingkup peke rjaan untuk usaha desain. Sangat penting bahwa pembuat keputusan utama-klien-pemilik-memungkinkan partisipasi dari semua stakeholder, atau klien-pengguna, yang dipengaruhi oleh desain. Pengalaman menunjukkan bahwa keterlibatan klien pengguna dalam hasil proses pemrograman dalam desain yang dapat dioptimalkan lebih efisien. Mengorganisir untuk Usaha Pemrograman Foto pertemuan komite proyek pemrograman dalam proses Pemrograman desain harus melibatkan pihak-pihak yang t erpengaruh oleh solusi desain. Sebelum awal proses pemrograman proyek, programmer dan klien-pemilik mengembangkan daftar para pemangku kepentingan untuk terlibat. Salah satu metode organisasi untuk membentuk Komite Proyek
Pemrograman dengan wakil-wakil dari kelompok stakeholder. Sebagai contoh, jika proyek ini adalah untuk menjadi kantor / bangunan kelas untuk departemen humaniora di sebuah institusi pendidikan tinggi, Komite Pemrograman Proyek dapat mencakup perwakilan dari departemen akademik yang terlibat (s), fakultas, mahasiswa, dan operasi bangunan dan fasilitas departemen pemeliharaan. Jalur komunikasi harus ditetapkan untuk menentukan bagaimana dan kapan pertemuan akan disebut, apa agenda yang akan, bagaimana kontak akan dibuat, dan bagaimana catatan pertemuan akan disimpan. Kewenangan Komite harus dibuat jelas. Dalam contoh di atas, wewenang komite akan membuat rekomendasi kepada pihak kampus. Dalam kerangka itu, panitia harus memutuskan bagaimana ia akan membuat keputusan sebagai komite (berdasarkan konsensus mayoritas?? Cara lain?). Sebuah Proses Enam Langkah Diagram alir yang menggambarkan proses enam langkah pemrograman Banyak format pemrograman yang berbeda menggabungkan unsur penting yang sama. Dalam semua kasus, program desain sesuai dalam konteks yang lebih besar perencanaan upaya yang juga dapat diprogram. Untuk pemrograman desain untuk bangunan, kami mengusulkan proses enam langkah sebagai berikut: Penelitian jenis proyek Menetapkan tujuan dan sasaran Mengumpulkan informasi yang relevan Mengidentifikasi strategi-strategi Tentukan persyaratan kuantitatif Meringkas program 1) Penelitian Jenis Proyek Langkah ini diperlukan jika programmer bekerja pada sebuah jenis proyek untuk pertama kalinya. Programmer harus menjadi akrab dengan beberapa informasi yang relevan sebagai berikut: Jenis-jenis ruang yang sering termasuk dalam jenis bangunan, Kriteria ruang (jumlah kaki persegi per orang atau unit) untuk ruangan-ruangan, Khas hubungan ruang untuk fungsi ini, Khas rasio rekaman persegi bersih dialihkan (NASF-daerah yang ditugaskan untuk fungsi) untuk rekaman persegi bruto (GSF-total area dinding luar) untuk jenis bangunan, Khas biaya per kaki persegi untuk jenis bangunan, Khas situs persyaratan untuk jenis proyek, Daerah masalah yang mungkin mengubah akurasi data di atas dalam kasus proyek ini, dan Teknis, mekanik, listrik, keamanan, atau isu-isu lainnya yang unik untuk jenis proyek. Informasi ini dapat diperoleh dari literatur pada jenis bangunan, analisis rencana proyek yang ada,
konsultan ahli akrab dengan jenis bangunan, dan / atau jasa estimasi biaya. 2) Menetapkan Tujuan dan Sasaran Bekerja dengan panitia, programmer solicits dan menyarankan pernyataan tujuan yang luas yang akan memandu sisa dari proses pemrograman. (. Lihat Tujuan Desain di situs Web WBDG) Masing-masing kategori berikut tujuan harus ditangani: Tujuan Organisasi: Apa tujuan dari pemilik? Di mana mer eka melihat organisasi mereka menuju? Bagaimana arsitektur proyek ini masuk ke dalam gambaran yang luas? Bentuk dan Gambar Tujuan: Apa yang harus menjadi dampak estetika dan psikologis dari desain? Bagaimana seharusnya itu berhubungan dengan lingkungan? Haruskah citranya menjadi serupa dengan atau berbeda dari negara tetangga? Dar i bangunan lain milik pemilik yang terletak di tempat lain? Apakah ada sejarah, budaya, dan / atau implikasi konteks? Fungsi Tujuan: Apa fungsi utama akan berlangsung di gedung itu? Berapa banyak orang yang harus diakomodasi? Bagaimana desain bangunan meningkatkan atau dampak interaksi penghuni? Tujuan Ekonomi: Apa anggaran total proyek? Bagaimana sikap terhadap biaya awal dibandingkan jangka panjang operasi dan biaya pemeliharaan? Apa tingkat kualitas yang diinginkan (sering dinyatakan dalam kaitannya dengan proyek-proyek lain yang sudah ada)? Bagaimana sikap terhadap konservasi sumber daya dan keberlanjutan (energi, air, dll)? Tujuan Waktu: Kapan proyek untuk ditempati? Apa jenis perubahan yang diharapkan dalam kurun waktu 5,, 10 15, dan 20 tahun? Tujuan Manajemen: Tujuan ini tidak begitu banyak masalah sifat proyek karena mereka adalah keadaan pemilik, klien, programmer, atau arsitek. Misalnya, mungkin desain skematik harus diselesaikan dalam waktu untuk tenggat waktu aplikasi permintaan legislatif. 3) Kumpulkan Informasi yang relevan Berdasarkan tujuan, kategori informasi yang relevan dapat ditentukan dan diteliti. Kategori khas meliputi: Fasilitas pengguna, kegiatan, dan jadwal: Siapa yang melakukan apa, berapa banyak orang yang melakukan aktivitas masing-masing, dan ketika mereka melakukannya? Peralatan apa yang diperlukan untuk kegiatan berfungsi dengan benar? Apa ukuran peralatan? Apa aspek proyek harus diproyeksikan ke masa depan? Apa sejarah pertumbuhan setiap aspek yang memerlukan proyeksi? Apa kriteria ruang (kaki persegi per orang atau unit) untuk fungsi-fungsi untuk mengambil tempat? Apa kriteria desain lainnya dapat mempengaruhi pemrograman arsitektur: akses untuk siang hari, akustik, aksesibilitas, kampus / pedoman desain daerah, pelestarian bersejarah, dll? Apakah ada lisensi atau kebijakan standar luas minimum untuk berbagai fungsi? Apa standar-standar ini? Apa penggunaan energi dan persyaratan? Apa informasi kode pemrograman dapat m empengaruhi keputusan?
Analisis situs: situs selalu merupakan aspek utama dari masalah desain dan karena itu harus dimasukkan dalam program. Komponen analisis situs yang sering mempengaruhi desain meliputi: Hukum Deskripsi Zonasi, pedoman desain, pembatasan perbuatan dan dan persyaratan Lalu lintas (bus, mobil, dan pe jalan kaki) pertimbangan Ketersediaan utilitas (item biaya yang berpotensi tinggi) Topografi Dilihat Dibangun fitur Iklim (jika tidak akrab bagi desainer) Vegetasi dan satwa liar Klien yang sudah ada fasilitas sebagai sumber daya Jika klien sudah berpartisipasi dalam kegiatan yang akan ditempatkan di fasilitas baru, dimungkinkan untuk menggunakan informasi di tangan. Menentukan apakah fasilitas yang ada memuaskan atau usang sebagai sumber daya. Jika ada rencana lantai, kaki persegi melakukan take-off dari daerah untuk berbagai fungsi. Tentukan efisiensi bangunan (rasio yang ada net-to-gross area). Rasio ini berguna dalam membangun target efisiensi bangunan untuk fasilitas baru. Jika klien adalah pembangun mengulang (sekolah kabupaten, perpustakaan umum, gedung perkantoran umum, dll), mendapatkan rencana dan melakukan take-off wilayah; menentukan efisiensi bangunan khas. Gunakan footages persegi yang ada untuk perbandingan ketika Anda mengusulkan jumlah ruang masa depan. Orang bisa berhubungan dengan apa yang telah mereka miliki. (Lihat ilustrasi di atas dalam Langkah 5, Tentukan persyaratan kuantitatif.) 4) Mengidentifikasi Strategi Strategi program menyarankan cara untuk mencapai tujuan yang diberikan apa yang kini tahu tentang peluang dan kendala. Sebuah contoh akrab strategi program adalah hubungan atau "gelembung" Diagram. Diagram ini menunjukkan apa fungsi harus dekat satu sama lain agar proyek untuk berfungsi dengan lancar. Diagram hubungan juga dapat menunjukkan hubungan yang diinginkan antara ruang sirkulasi, ruang apa yang memerlukan privasi keamanan atau audio, atau aspek lain dari hubungan khusus. Lain jenis strategi terulang dalam program untuk berbagai jenis proyek. Be berapa contoh kategori umum dari strategi program meliputi: Sentralisasi dan desentralisasi: fungsi komponen Apa yang dikelompokkan bersama dan yang dipisahkan? Sebagai contoh, di beberapa kantor fungsi menyalin terpusat, sementara di lain ada mesin fotokopi untuk setiap departemen. Fleksibilitas: Apa jenis perubahan yang diharapkan untuk berbagai fungsi? Apakah fasilitas perlu mengubah selama beberapa jam? Beberapa hari? Sebuah istirahat musim panas? Atau tambahan apa
yang benar-benar diperlukan? Arus: Apa barang, jasa, dan orang-orang bergerak melalui proyek? Apa yang dibutuhkan pada setiap langkah dari jalan untuk mengakomodasi aliran itu? Prioritas dan pentahapan: Apa fungsi paling penting dari proyek ini? Apa yang bisa ditambahkan kemudian? Apakah ada operasi yang ada berkelanjutan yang harus dipertahankan? Tingkat akses: Siapa yang diperbolehkan di mana? Apa tingkat keamanan yang ada? Idealnya, setiap tujuan dan sasaran yang diidentifikasi dalam Langkah 2 akan memiliki semacam strategi untuk mengatasi tujuan tersebut. Jika tidak, baik tujuan tidak terlalu penting, atau diskusi lebih lanjut diperlukan untuk mengatasi bagaimana untuk mencapai tujuan at au objektif. 5) Menentukan Persyaratan Kuantitatif Biaya siklus ilustrasi Biaya, jadwal, dan area terjangkau saling bergantung. Biaya dipengaruhi oleh inflasi melalui waktu. Terjangkau daerah ditentukan oleh anggaran yang tersedia. Pada langkah ini, seseorang harus mendamaikan anggaran yang tersedia dengan jumlah yang diinginkan perbaikan dalam jangka waktu proyek. Pertama, daftar ruang yang dikembangkan untuk mengakomodasi semua kegiatan yang diinginkan (lihat Exhibit A). Kriteria ruang diteliti pada Langkah 3 adalah dasar dari daftar kebutuhan ruang. Kebutuhan ruang yang terdaftar sebagai bersih kaki persegi dialihkan (NASF), mengacu pada ruang ditugaskan untuk suatu kegiatan, tidak termasuk sirkulasi ke ruang tersebut. Sebuah persentase untuk ruang "tara" ditambahkan ke NASF total. Tare ruang adalah area yang diperlukan untuk sirkulasi, dinding, mekanik, peralatan listrik dan telepon, ketebalan dinding, dan toilet umum. Efisiensi bangunan adalah rasio NASF untuk kaki persegi bruto (GSF), total luas termasuk daerah NASF dan tara. Efisiensi bangunan sama NASF / GSF. Efisiensi bangunan untuk jenis bangunan diteliti pada Langkah 1 dan mungkin Langkah 3. Lihat Lampiran A untuk contoh kebutuhan ruang. Efisiensi membangun sebuah ruang yang ada digunakan oleh klien dapat menginformasikan pemilihan rasio net-untuk-kotor. Contoh di bawah ini dari sebuah office suite dalam sebuah gedung perkantoran menggambarkan bidang bersih meter persegi dialihkan dan area tara. Per hatikan bahwa beberapa ruang dalam kantor dianggap sirkulasi, meskipun tidak digambarkan dengan dinding. Kami menyebutnya sirkulasi, "koridor hantu." Sebuah office suite dalam sebuah bangunan kantor yang menggambarkan daerah bersih meter persegi dialihkan dan area tara. Dalam kasus perbaikan penyewa dalam gedung yang lebih besar, salah menetapkan "kotor internal" dari ruang sewa. Dukungan ruang tambahan atau daerah tara sepe rti ruang mekanik dan toilet umum tidak akan dimasukkan dalam perhitungan untuk jenis proyek. GSF diinginkan kemudian diuji terhadap anggaran yang tersedia (lihat Exhibit B). Dalam penyusunan
biaya total proyek, programmer menggunakan biaya per jumlah kaki persegi diteliti pada Langkah 1. Faktor inflasi harus dimasukkan, berdasarkan jadwal proyek. Biaya harus diproyeksikan untuk tanggal titik tengah konstruksi karena penawar menghitung perkiraan pada asumsi bahwa biaya dapat berubah dari waktu tanggal penawaran. Total biaya proyek meliputi biaya konstruksi (untuk bangunan dan tempat kerja), ditambah jumlah untuk biaya arsitek, furnitur dan peralatan, komunikasi, kontingensi, pencetakan untuk set tawaran, kontingensi, tes tanah, survei topologi, dan biaya lain yang harus datang dari anggaran pemilik. Tujuannya adalah untuk membantu pemilik mempersiapkan semua biaya proyek, bukan hanya mereka yang ditugaskan untuk biaya konstruksi. Jika garis bawah untuk biaya proyek lebih dari anggaran, tiga hal dapat terjadi: 1) ruang bisa dipangkas kembali atau didelegasikan ke fase kemudian (pengurangan kuantitas), 2) biaya per kaki persegi dapat dikurangi ( pengurangan dalam k ualitas), atau 3) keduanya. Ini rekonsiliasi ruang yang diinginkan dan anggaran yang tersedia sangat penting untuk mendefinisikan ruang lingkup pekerjaan yang realistis. 6) Program Meringkas Akhirnya, setelah semua langkah se belumnya dijalankan, laporan ringkasan dapat ditulis mendefinisikan "di shell kacang" hasil dari upaya pemrograman. Semua informasi yang relevan termasuk di atas dapat didokumentasikan untuk pemilik, anggota komite, dan tim desain juga. Para pengambil keputusan harus sign-off pada lingkup pekerjaan seperti yang dijelaskan dalam program ini. Setelah program selesai dan disetujui oleh klien, informasi harus diintegrasikan ke dalam proses desain. Beberapa klien ingin programmer untuk tetap terlibat set elah fase pemrograman untuk memastikan bahwa persyaratan yang ditentukan dalam program yang diwujudkan dalam karya desain. Kembali ke atas Muncul Isu Beberapa isu yang muncul dalam disiplin arsitektur pemrograman meliputi: Pengembangan standar dan pedoman bagi pemilik yang membangun fasilitas serupa sering. Upaya ini meliputi: Formalisasi (komputerisasi) persyaratan fasilitas bangunan untuk konsumsi berbasis Web-misalnya, Service Taman Nasional telah mengembangkan Fasilitas Model Perencanaan perangkat lunak berbasis Web untuk membantu kepala taman dan staf lain dalam pengembangan prediksi ruang dan biaya untuk permintaan legislatif. Tujuannya adalah untuk membuat permintaan anggaran yang lebih realistis dan lebih komprehensif. Fasilitas pemrograman untuk membuat prediksi awal untuk membantu dalam penganggaran modal awal Klien-pemilik semakin membutuhkan verifikasi bahwa desain sesuai dengan program. Teknologi baru yang menghasilkan kebutuhan untuk jenis ruang yang tidak memiliki preseden. Penelitian dasar pada teknologi ini diperlukan untuk menentukan standar dan pedoman.
Sebagai klien lebih membutuhkan langkah-langkah untuk energ i bangunan dan standar konservasi sumber daya (LEED, Globe Hijau, dll), proses pemrograman harus mencerminkan persyaratan dalam tujuan, biaya, penjadwalan, dan proses. Pasokan programmer fasilitas lebih kecil dari permintaan. Lebih profesional perlu mempertimbangkan hal ini sub-disiplin sebagai jalur karir. Kembali ke atas Relevan Kode dan Standar Sebuah bagian yang sangat penting dari pemrograman adalah mengidentifikasi kode yang relevan dan standar yang berlaku untuk proyek (lihat Langkah 1 dan 3 di atas). Kode, perjanjian, perbuatan pembatasan, persyaratan zonasi, persyaratan per izinan, dan kewajiban hukum lainnya dapat memiliki pengaruh yang signifikan pada biaya dan oleh karena itu, GSF te rjangkau. Faktor-faktor ini harus diidentifikasi sebelum desain. Banyak pemerintah dan lembaga telah mengembangkan standar dan pedoman untuk alokasi ruang. Sebagai contoh, Administrasi Layanan Umum (GSA), militer, dan institusi pendidikan tinggi semua memiliki standar dan pedoman. Standar ini harus ditaati dalam proyek-proyek pemrograman untuk klien-klien ini. Standar ini juga berguna sebagai pedoman bagi instansi yang belum mengembangkan standar mereka sendiri. Beberapa standar yang diamanatkan oleh undang-undang dalam beberapa wilayah yurisdiksi untuk lisensi, akreditasi, atau tujuan ekuitas. Sekolah, rumah sakit, fasilitas pemasyarakatan, dan lembaga berlisensi atau terakreditasi lainnya mungkin diperlukan untuk memenuhi standar sebelum membuka pintu mereka. Beberapa kode bangunan mengidentifikasi jumlah kaki persegi dialokasikan per orang untuk beberapa jenis hunian. Namun, sementara rasio-rasio dapat menentukan jumlah hunian hukum untuk fasilitas, persyaratan keluar, api perpisahan, dll, mereka mewakili persyaratan minimum. Mungkin perlu untuk mengakomodasi kegiatan-kegiatan khusus memadai dengan lebih banyak ruang. Kembali ke atas Mayor Sumber Daya WBDG Desain Bimbingan Ruang Jenis, Jenis Bangunan Dokumen dan Referensi Studi Kasus, Federal Mandat Desain Disiplin Memperkirakan Biaya untuk diskusi tentang estimasi biaya konseptual.
Tujuan desain Biaya-Efektif untuk memperkirakan biaya tambahan sumber daya perangkat lunak. Sumber untuk Kriteria Space dan Proyek Penelitian Je nis Grafis desain standar dan sumber-sumber standar lainnya: AIA Jenis Bangunan seri Distrik sekolah dan / atau Departemen Pendidikan National Park Service Model Perencanaan F asilitas (Koleksi Museum Fasilitas, Fasilitas Pemeliharaan, Fasilitas Pendidikan, Sarana dan Fasilitas Pe ngunjung Administrasi) oleh Konsultan Penelitian Arsitektur, Incorporated: Albuquerque, NM, 2004-2005. Perangkat lunak komputer. Akreditasi lembaga Negara, daerah, dan lembaga kota, lisensi dan regulasi. Bibliografi Pemrograman Arsitektur: Teknik Kreatif untuk Profesional Desain oleh R. Kumlin. New York, NY: McGraw-Hill, Inc, 1995. Pemrograman Arsitektur, Manajemen Informasi untuk Desain oleh DP Duerk. New York, NY: Van Nostrand Reinhold, 1993. "Fasilitas Perencanaan pada Skala Besar: Polisi New Mexico State Fasilitas Master Plan" oleh John Petronis, AIA, AICP di Pemrograman Lingkungan Dibangun diedit Wolfgang FE Preiser. New York, NY: Van Nostrand Reinhold, 1985. Bab 12.1, "Pemrograman" oleh Edith Cherry, FAIA, ASLA, dalam Handbook Arsitek dari Praktek Profesional oleh American Institute of Architects. Washington DC, 2008. Soal Mencari: Sebuah Primer Pemrograman Arsitektur, Edisi 4 oleh WM Peña dan S. A. Parshall. New York, NY: John Wiley & Sons, Inc, 2001. Profesional Praktek di Pemrograman Fasilitas oleh WFE Preiser. New York, NY: Van Nostrand Reinhold, 1993. Pemrograman untuk Desain: Dari Teori ke Praktek oleh E. Cherry. New York, NY: John Wiley & Sons, Inc, 1998. Pemrograman Lingkungan Dibangun oleh W.F.E. Preiser. New York, NY: Van Nostrand Reinhold, 1985 ed. Proyek Pemrograman, Sebuah Layanan Arsitektur Tumbuh oleh ET Putih. Tucson, Arizona: Arsitektur Media Ltd, 1991. Data Biaya persegi Kaki dan Data Biaya Konstruksi Bangunan oleh RS Sarana. 100 Konstruksi Plaza, P.O. Kotak 800, Kingston, MA, 02364-0800 , diterbitkan setiap tahunnya. "Nilai: Sebuah Yayasan Teoritis untuk Pemrograman Arsitektur" di Pemrograman Lingkungan Dibangun oleh R. Hershberger. New York, NY: Van Nostrand Reinhold, 1985. Bukti J: Persyaratan Ruang (PDF 86 KB, 2 pgs)
Dalam contoh ini kebutuhan ruang, daftar ini dibagi menjadi dua bagian yang mewakili ruang dengan biaya konstruksi secara signifikan berbeda. Bukti B: Contoh Anggaran Proyek Jumlah (PDF 51 KB, 1 pg) Perhatikan bahwa Biaya Konstruksi, E Line, secara signifikan kurang dari total biaya proyek. Klien per lu tahu apa yang akan biaya total proyek, bukan hanya biaya konstruksi.
