Terjemahan

Matikan terjemahan instan

2528/5000
Ketika pondasi yang dibangun sebelum desain selesai untuk bangunan, para
desainer harus benar mengantisipasi konfigurasi dan beban bangunan atas.
Hampir pasti, ini mengarah untuk menguasai rencana dengan lokasi untuk unit
bangunan diskrit dan untuk bangunan sederhana dengan luas lantai terbuka,
bebas rentang, yang akan memungkinkan salah satu diantisipasi tetapi belum
menggunakan unprogarammed cocok cukup baik. Biasanya ini melibatkan kedua
penyederhanaan dari dan lebih ukuran ruang dan jasa. Oleh karena itu menjadi
pengaruh penting pada desain, memiliki efek mendalam pada bentuk bangunan.
Hal ini juga mungkin memiliki efek pada anggaran proyek, meningkatkan biaya
desain, tapi mungkin mengurangi konstruksi dan pembiayaan biaya. Ini ketat
seperti itu wajib, semua potensi biaya dan tabungan harus diberikan perhatian,
untuk memastikan bahwa pekerjaan akan tetap dalam anggaran proyek.
Sehubungan dengan persyaratan waktu konstruksi, berarti memiliki beberapa
panduan bermanfaat yang berkaitan dengan waktu yang dibutuhkan untuk
membangun beberapa jenis bangunan. Hal ini juga menunjukkan bahwa waktu
desain biasanya berjalan 25 sampai 40 persen dari waktu konstruksi (gbr. 7-66)
Programmer harus mengembangkan catatan yang akurat dari waktu yang
dihabiskan dari berbagai tahapan desain dan konstruksi proses pada setiap
komisi sehingga selama periode waktu mereka akan dapat membuat prediksi
yang cukup akurat untuk waktu (dan sumber daya personil) yang akan
diperlukan untuk mencapai setiap tahap pekerjaan. Hal ini dapat membantu
untuk klien dan arsitek karena mereka bergerak maju dengan proyek.
analisis desain
ide-klien
-precedents
konsep -programmatic
sila -design
konsep desain jembatan
eksplorasi -design
Mungkin juga ada ide tentang solusi desain yang tepat bahwa klien, pengguna,
atau programmer ingin arsitek untuk dipertimbangkan ketika merancang proyek.
Ini bukan persyaratan biasanya dipertimbangkan untuk desain, hanya ide-ide
yang telah datang dalam perjalanan dari wawancara atau bekerja sesi
diagnostik. Jika mereka tampaknya ide yang baik untuk klien dan programmer,
mereka mungkin layak termasuk dalam program ini, bukan sebagai persyaratan
desain, tapi mungkin arah untuk desainer untuk mengeksplorasi ketika
merumuskan solusi desain.
Ide-ide tentang desain harus disimpan dalam bagian penutup yang terpisah dari
program atau dalam lampiran, karena mereka adalah awal dari proses desain
arsitektur bukan merupakan bagian integral dari program arsitektur. Fakta bahwa
ide-ide desain maju sementara orang-orang yang
mengingat alam untuk mempertimbangkan solusi ketika mendefinisikan
masalah. Harus diakui, bagaimanapun, bahwa gagasan-gagasan ini prasangka,
tidak merancang konsep atau solusi. Memang, sebagai masalah desain exproled,
maka akan ditemukan bahwa beberapa ide sama sekali tidak tepat dan harus
dibuang, desain keseluruhan. Dalam kasus apapun, ide-ide yang ditetapkan
setiap saat selama proses pemrograman harus dicatat dan diringkas dalam
bagian dokumen Program.
IDEAS CLIENT
kasus klasik ini dari ide-ide desain yang ditawarkan selama pemrograman,
mungkin, adalah bahwa dari pasangan yang telah mengumpulkan seluruh
lembar memo ide dari rumah yang lebih baik dan kebun, matahari terbenam,
dan majalah lain yang menurut mereka bagus dan dapat dimasukkan ke dalam
desain rumah baru mereka. Klien di perusahaan, bisnis, dan lembaga juga
mungkin memiliki ide-ide desain, mungkin didasarkan pada jurnal perdagangan
atau pengalaman pribadi dengan buildingarrangements sangat efektif atau tidak
efektif. Beberapa arsitek pemula dapat memilih untuk mengabaikan ide-ide
seperti, merasa mereka adalah ancaman untuk kebutuhan arsitek untuk ekspresi
desain pribadi, namun banyak desainer berpengalaman dan programmer akan
mendorong klien untuk mengumpulkan dan melestarikan bahan ini sebagai bank
data ide-ide desain. Ada alasan untuk percaya bahwa orang-orang yang
menggunakan fasilitas akan memiliki ide setidaknya sone baik tentang solusi
untuk aspek-aspek tertentu dari masalah desain. Pertanyaannya adalah
bagaimana cara terbaik untuk menyajikan ide-ide ini dan tidak memiliki mereka
menjadi prasangka desain dengan yang desainer dipaksa untuk bekerja. Penulis
merasa bahwa memperlakukan mereka hanya sebagai ide-ide desain daripada
konsep desain adalah pendekatan yang tepat (gbr. 7-67)
Jika ide-ide yang diambil dari majalah atau dokumen lainnya yang dipublikasikan,
mereka dapat difotokopi dan disertakan dengan catatan kaki mengkredit sumber
dan menunjukkan mengapa ide itu dianggap tepat untuk solusi desain.
Jika klien atau pengguna mengakui bahwa programmer telah diterima dan
dicatat ide-ide mereka, mereka jauh lebih mungkin untuk bersimpati dengan
solusi desain akhir, bahkan jika beberapa atau bahkan sebagian besar ide-ide
mereka kita tidak dimasukkan ke dalam desain.
Jika klien atau pengguna saran yang diberikan secara lisan, mereka harus dicatat
dan dimasukkan dalam matriks pemrograman bawah ide, programmer harus
mengembangkan sketsa sesuai atau preceptdiagrams untuk membuat ide-ide
lebih jelas (gbr. 7-68)
gambar yang diinginkan diamati oleh programmer dalam pembentukan klien
yang ada ditunjukkan pada (gambar 7-69)
PRESEDEN
Informasi tentang bangunan serupa yang dikumpulkan selama fase tinjauan
literatur atau pemrograman arsitektur harus dimasukkan dalam lampiran.
Namun, fitur sangat relevan dari bangunan ini atau konstanta tipologis harus
dimasukkan dalam bagian ide-ide program untuk desainer untuk
mempertimbangkan. programmer harus mencoba untuk memastikan dari solusi
sebelumnya jika norma budaya ada atau jika pengaturan yang sangat logis telah
datang untuk mengkarakterisasi jenis bangunan tertentu, dan apakah
keberangkatan dari norma cenderung mengganggu efektivitas solusi desain.
Dengan kata lain, jika solusi logis untuk jenis bangunan tertentu telah dibuktikan,
tugas desain arsitek mungkin tidak menjadi untuk menemukan kembali tipologi
penting ini, melainkan untuk beradaptasi dengan masalah dan situs tertentu di
tangan dengan cara seperti untuk memenuhi tujuan dan memenuhi persyaratan
program tertentu.
Sebuah contoh kontemporer ini adalah pusat perbelanjaan sudut berbentuk L
yang mencirikan begitu banyak persimpangan utama dalam mengembangkan
wilayah di Amerika Serikat. Pola ini berulang memuakkan, ke titik di mana
hampir semua orang ingin sesuatu yang lebih unik atau kreatif dapat dicapai.
Namun, ketika pendekatan unik mencoba, mereka tampaknya gagal untuk
menarik intensitas yang sama penggunaan, sehingga para pengembang kembali
lagi ke prototipe yang sama (gbr. 7-70)
Para pengembang pusat perbelanjaan Di Tempe, Arizona di sisi lain, ternyata
khas "L" di sekitar dan menciptakan perbelanjaan yang sukses adalah dengan
parkir di belakang bangunan daripada di depan mereka. Pendekatan ini
tampaknya telah bekerja dalam situasi ini; Namun, pengaturan menghalangi
memiliki area layanan pintu belakang untuk toko-toko, membatasi jenis Toko
yang dapat terletak di pusat (Fig.7-71)
Di sisi lain, beberapa arsitek dan Urbanis lainnya panjang untuk jalan-jalan
belanja berorientasi pedestrian- dan kotak yang melambangkan kota-kota dan
desa-desa di seluruh Eropa dan beberapa kota pre-auto-mobile dan masyarakat
di Amerika Serikat. Murray Silverstein dan Max Jacobson (1985) membuat
argumen yang meyakinkan untuk program alternatif untuk pasar masyarakat
(Fig.7-72)
arsitek kontemporer lainnya dan perencana advokasi untuk urbanisme baru
telah membuat permohonan serupa untuk jalan-jalan pejalan kaki yang
berorientasi dan belanja daerah (Kelbaugh 1989; Katz et.al. 1994)
argumen yang sama untuk pendekatan alternatif untuk berbagai jenis bangunan
disajikan di Alexander et al. Bahasa Pola (1977) dan The Oregon Percobaan
(1975). Buku lain, Preseden dalam Arsitektur oleh Roger Clark (1985),
menunjukkan diagram dari berbagai sistem untuk berbagai jenis bangunan.
Dalam kasus apapun, pencarian literatur-hati harus mengungkapkan beberapa
alternatif pola atau pendekatan yang dapat disajikan untuk kedua klien dan
desainer untuk pertimbangan mereka.
Konsep program
Dalam Soal Mencari (1969,1977,1987) William Pena dkk berpendapat untuk
termasuk konsep program dalam dokumen Program. Ia mendefinisikan konsep
program sebagai konsep-konsep tersebut
memiliki implikasi terutama organisasi atau operasional. Gambar 7-73
mengilustrasikan terintegrasi versus terkotak sebagai konsep program.
kartu konsep program yang sama dapat digunakan secara efektif untuk visual
menjelaskan banyak ide program yang disajikan selama proses pemrograman.
(Gambar 7-74)
Dengan banyak konsep program ada yang penting untuk implikasi. Misalnya,
dalam program untuk perluasan College of Arsitektur dan Lingkungan Desain di
Arizona State University dan College of Arsitektur di Universitas Arizona,
perbedaan yang nyata dalam sikap tentang sifat dari pendidikan desain
mengakibatkan program yang berbeda konsep untuk pengaturan studio desain.
Di Arizona State University, diputuskan bahwa setiap studio desain harus
terpisah dari yang lain untuk memungkinkan siswa untuk mengamankan
komputer mereka dan peralatan pribadi lainnya di ruang terkunci. Di The
University of Arizona, mahasiswa dan fakultas mengindikasikan bahwa mereka
ingin besar, terbuka, bahkan tahun berganda dan beberapa studio disiplin untuk
meningkatkan interaksi sosial dan kolaborasi antara fakultas dan mahasiswa.
Keamanan workstation individu dan peralatan begitu penting. komputer laptop
portabel dan dimiliki secara pribadi trans didorong untuk mengurangi potensi
pencurian di lingkungan yang tidak aman. Perbedaan di atas adalah program di
alam, tetapi memiliki implikasi yang formal sangat kuat.
Ide tersebut dapat dinyatakan dalam diagram untuk membuat mereka lebih
dimengerti untuk desainer daripada jika mereka dinyatakan hanya dalam kata-
kata (Gbr. 7-75 dan 7-76). Sementara diagram konsep program tersebut tidak
secara spesifik menunjukkan bagaimana studio harus dirancang, ada implikasi
resmi kuat bahwa, jika ditanggapi oleh desainer, akan menghasilkan desain yang
sangat berbeda (dan kegiatan studio).

Sila desain
Profesor Edward T. White (1972) mengembangkan ide menggunakan diagram
ajaran solusi parsial untuk merancang masalah sebagai langkah terakhir dalam
pemrograman. Ketika desainer adalah bagian dari tim pemrograman, ini adalah
cara yang berarti untuk mengeksplorasi dampak desain berbagai keputusan
program sebelum mencoba untuk mengembangkan konsep desain keseluruhan.
Ada enam konsep atau persepsi kartu dapat dikurangi dalam ukuran dan
ditampilkan pada satu halaman dari dokumen Program (Gambar 7-77).
penjelasan verbal dapat ditambahkan di bawah atau ke satu sisi. Penurunan ini
dimungkinkan karena kartu diambil dan berhuruf pada skala besar sehingga
dapat dengan mudah dilihat dari 10 menjadi 15 kaki dalam sesi kerja.
Perhatikan bagaimana ajaran dapat diagram, fisik, atau bahkan metafora di alam
dan dalam cara mereka disajikan. Ini tidak ada masalah asalkan semua orang
mengerti bahwa mereka semua hanya ide-prasangka tentang bagaimana desain
akhir mungkin menanggapi masalah desain. Jika mereka adalah
termasuk dalam dokumen program dengan cara ini, mereka memberikan arsitek
desain manfaat dari semua ide ditemukan dalam ide-ide pemrograman proses-
ditemukan dalam ide-ide literatur, klien dan pengguna, dan programmer
penyulingan semua ide-ide ini. Jika semua orang mengerti bahwa mereka hanya
saran, bukan persyaratan, perancang harus mendapatkan keuntungan dari
wawasan ditambahkan (Gambar. 7-78 melalui 7-80)
Konsep desain
Jika desainer adalah anggota tim pemrograman, juga memungkinkan untuk
memulai pengembangan konsep desain diagram sebagai bagian penutup dari
kegiatan pemrograman. Ini berfungsi baik sebagai cara untuk mengkonfirmasi
kemanjuran dari informasi program dan sebagai cara bagi klien untuk
mengevaluasi apakah konsep ini sesuai untuk masalah fasilitas tertentu klien.
Hal ini dapat menunjukkan, seperti dalam ilustrasi yang berdekatan, bagaimana
nilai yang dipegang teguh dapat memiliki dampak besar pada bentuk arsitektur
(Gambar 7-81)
Sebuah proses untuk menciptakan konsep desain telah dikembangkan dengan
baik oleh Profesor Edward T. White dari Florida A & M University (1990).
Pendekatan ini analitik untuk mengembangkan konsep desain berfokus pada isu-
isu tertentu. Pendekatan pertama dimulai dengan diagram konsep fungsional. Di
sini, diagram hubungan tradisional yang dihasilkan untuk seluruh bangunan,
mengakui dari awal bahwa setiap diagram holistik akan didasarkan pada asumsi
organisasi tertentu. Akan satu entri berfungsi sebagai titik penerimaan untuk
semua divisi organisasi atau akan beberapa entri disediakan untuk lebih mudah /
akses langsung ke setiap divisi? Yang akan melayani klien yang lebih baik? Apa
implikasi staf? Harus program diubah untuk mencerminkan persyaratan baru
untuk staf? Harus semua kantor tertutup akan berkumpul di satu area dan
semua kantor terbuka ditempatkan bersama-sama di lokasi lain? Apakah ini
masuk akal fungsional? Apakah akan menghemat uang dalam hal biaya
struktural dan atau konstruksi?
Sangat diagram bubble sederhana yang digunakan untuk mengeksplorasi
implikasi dari pengaturan fungsional dalam hal operasi, efisiensi, biaya
konstruksi, biaya staf, dll Pertama, White mengembangkan diagram hubungan
secara keseluruhan. Dia kemudian memutuskan cara-cara alternatif bahwa
bangunan dapat dikategorikan. Akhirnya, ia berasal beberapa diagram desain
berdasarkan setiap keputusan zonasi ini untuk melihat apa implikasinya adalah
untuk desain (Gambar 7-82).
Diagram Hubungan zonasi dan konsep desain awal yang dihasilkan menunjukkan
seberapa efektif diagram tersebut dapat membantu arsitek mengembangkan
konsep desain. Contoh menunjukkan bahwa ada keputusan zonasi yang jelas
berbeda dapat dibuat dari diagram hubungan yang identik secara keseluruhan,
dan bahwa dampak dari setiap pendekatan pada solusi desain mungkin akan
sangat besar. Rencana yang dihasilkan sama sekali tidak mirip dalam bentuk
atau potensial estetika.
Pengelompokan fungsi di zona juga dapat berguna dalam pemrograman untuk
reorganisasi fasilitas yang ada, termasuk ruang luar yang terkait. Dalam ilustrasi
sebelah, mereka diusulkan oleh konsultan pemrograman / desain sebagai cara
untuk memecahkan masalah program (Gambar. 7-83)
Apakah hubungan zonasi sesuai untuk dimasukkan dalam dokumen Program
tergantung pada apakah mereka mewakili keputusan terprogram oleh klien /
user, atau, pada kenyataannya, cara konseptual mendekati desain. Dalam kasus
terakhir, diagram pasti harus dibiarkan keluar dari persyaratan bagian dari
program. Ini dapat dimasukkan dalam ide-ide bagian dari program, di mana ia
dapat dievaluasi oleh desainer sebagai ide bukan sebagai suatu kebutuhan.
diagram analitik seperti tidak harus membatasi diri pada hal-hal fungsional.
Bagaimana jika diagram dimulai dengan situs atau konteks, bukan program
fungsional? Di mana akan dilihat, akses, lereng, fitur situs khusus, dan
sejenisnya menyarankan pintu masuk gedung, jasa, atau ruang utama berada?
Apakah ada cara lain bahwa situs tersebut mungkin lebih mengakomodasi
fasilitas? Jika iklim, terutama akses surya, dianggap, bagaimana hal itu akan
mempengaruhi atau mempengaruhi tata letak bangunan? Bagaimana jika akses
surya dianggap masalah yang paling penting?
Putih (1990) melanjutkan dengan menunjukkan cara diagram lainnya untuk
mengembangkan konsep desain yang menghasilkan hubungan resmi yang
berbeda bahwa yang dikembangkan dari diagram zonasi alternatif dan yang
memerlukan desainer untuk menangani hubungan fungsional dengan cara masih
lainnya (Gambar 7-84)
Bagaimana jika nilai-nilai estetika itu harus dipertimbangkan terlebih dahulu?
Apa yang harus bangunan seperti terlihat seperti, terlepas dari kendala
fungsional, situs, dan iklim? Ini akan membutuhkan sebuah diagram yang
berbeda dan perubahan yang sesuai dalam tata letak fungsional dan hubungan
ke situs dan iklim. Bagaimana jika anggaran wee yang paling penting
considerations- klien membutuhkan sejumlah besar ruang, tetapi memiliki sedikit
uang untuk membayar untuk itu? Ini akan sangat salah satu nilai utama yang
terdaftar sebelumnya dalam program (Gambar 7-85)
desain Eksplorasi
Jelas, sebagian besar teknik di atas merupakan bagian dari tahap eksplorasi awal
desain. Jika mereka capai selama pemrograman dan program akhir dimodifikasi
untuk mencerminkan temuan desain awal ini, hampir mengambil program
melalui fase skema awal desain. Tetapi juga membantu untuk menghindari
masalah arsitek harus menjelaskan kepada pemilik bahwa asumsi tertentu dari
program yang baik dalam kesalahan atau yang relatif realistis untuk beberapa
nilai-nilai dan tujuan yang diungkapkan.
Penulis pendukung termasuk eksplorasi desain dalam pemrograman hanya
ketika desainer yang terlibat dalam proses pemrograman, dan bahkan kemudian
dengan beberapa syarat. Ada beberapa alasan yang sangat baik untuk
rekomendasi ini.
Alasan pertama adalah bahwa konfirmasi program klien biasanya adalah
tanggung jawab pertama arsitek di bawah perjanjian pemilik / arsitek normal. Ini
merupakan kegiatan yang arsitek disiapkan untuk melakukan dengan pelatihan
dan pengalaman. Ini adalah apa yang mereka harapkan untuk dilakukan pada
awal masalah desain. Memang, itu adalah di mana nilai pendidikan yang luas
mereka datang ke dalam bermain dalam penyelesaian masalah tata ruang yang
sulit.
Alasan kedua adalah bahwa arsitek desain mungkin melihat kemungkinan lain
untuk solusi masalah yang tipologi sebelumnya, atau klien, pengguna, atau
pengalaman yang terbatas programmer, tidak akan mengizinkan untuk maju
selama pemrograman. Jika program ini didasarkan pada asumsi sempit daripada
tepat mengingat berbagai perancang kemampuan atau repertoar bentuk, maka
program bisa menjadi penghalang untuk solusi kreatif untuk program-halangan
daripada menerapkan karena ia penciptaan untuk arsitektur.
Akhirnya, bahkan jika desainer terlibat dalam pemrograman, penetapan dini cara
konseptual memecahkan masalah desain dapat menghambat eksplorasi
alternatif lain. Memang, mungkin memerlukan desainer untuk kembali ke pemilik
untuk menjelaskan mengapa strategi desain sebelumnya diadopsi tidak lagi
beroperasi. Ini adalah hal yang aneh dan kadang-kadang sulit untuk dilakukan.
Para desainer, pada dasarnya, harus membuktikan orang lain salah.
programmer tidak harus membatasi pilihan dengan memberlakukan kendala
yang tidak melekat dalam masalah. Jika desainer tidak terlibat dalam proses
pemrograman, adalah lebih baik untuk meninggalkan semua tetapi analisis
desain paling dasar untuk desainer, mengakui bahwa analisis tersebut dapat,
memang, memerlukan beberapa penyimpangan dari program awal. Selama klien
mengerti dan setuju bahwa ini adalah kemungkinan, itu tidak boleh dianggap
sebagai masalah pemrograman, melainkan sebuah kesempatan yang menjadi
dari desain.
Fakta bahwa pemrograman dan analisis desain yang benar-benar lengkap
sampai bangunan dibangun dan ditempati. Desain eksplorasi, desain skematik,
pengembangan desain, dan bahkan hunian utama bangunan akan mengungkap
ide-ide baru, peluang, dan kendala yang akan membuat beberapa tujuan dari
program asli sulit dicapai, dan sering akan menyebabkan klien untuk mengubah
pikiran mereka untuk persyaratan program.
Kesimpulannya, penulis berpendapat bahwa analisis desain adalah tanggung
jawab desainer dan harus di bawah / pengawasan nya langsungnya. Di sisi lain,
hal itu tidak berarti bahwa desainer harus mencapai analisis desain dalam cara
yang sama sekali tunggal. Sebaliknya, itu adalah sangat diinginkan untuk
desainer untuk meminta partisipasi klien, pengguna, dan programmer dalam
pengejaran umum, seperti mereka mengeksplorasi bersama-sama implikasi
desain dari seluruh program, termasuk semua ide-ide desain yang telah datang
ke depan selama arsitektur pemrograman.
Tanggung jawab untuk kualitas desain tinggal dengan desainer. Dengan
demikian, desainer harus memiliki kewenangan untuk membuat keputusan
desain.
7.14 Lampiran
Selalu ada beberapa materi yang penting sehingga tidak boleh hilang, karena
menjelaskan atau menguatkan beberapa informasi suling dalam program ini.
Informasi ini tidak harus ditempatkan di bagian utama dari program ini, namun
dapat ditempatkan dalam lampiran untuk program untuk referensi jika
diperlukan.
Satu-satunya informasi yang harus ditempatkan dalam tubuh program arsitektur
adalah bahwa yang akan memiliki dampak langsung pada keputusan desain.
programmer harus menjaga program singkat dan to the point, dengan informasi
penting yang berkaitan dengan merancang jelas ditetapkan dan diatur untuk
memudahkan pengambilan. Seperti yang dinyatakan sebelumnya, Satu ons
penjelasan bernilai satu ton keterangan. Atau, dengan kata lain, pemahaman
program oleh desainer berbanding terbalik dengan jumlah materi yang
disampaikan. Pikirkan tentang kedua katakan ketika mempertimbangkan
masuknya materi dalam program ini.
usus buntu harus berisi informasi yang diperoleh dari studi observasi pencarian
literatur, wawancara, kuesioner / survei, analisis situs, dan data lainnya yang
dikembangkan selama proses pemrograman. Jika program ini dengan hati-hati
dikembangkan, desainer bahkan tidak mungkin perlu merujuk ke usus buntu.
Namun, jika ada kebutuhan untuk melihat lebih informasi ini di beberapa titik
dalam proses desain, itu harus tersedia untuk referensi.
Jika program adalah satu besar, advokat penulis menempatkan bahan lampiran
dalam dokumen lepas terpisah dengan tab untuk menunjukkan di mana masing-
masing jenis bahan berada. Itu harus di 8 1/2 x 11 kertas sehingga dapat
disimpan atau diajukan oleh desainer dengan bahan proyek lainnya untuk
referensi siap yang diperlukan.