Principle of Project Management

Text posting disini

Prinsip Manajemen Proyek

Ada berbagai cara di mana proyek dapat didekati dan sejumlah 'metodologi', 'kerangka', dan 'proses' telah dikembangkan selama 60 tahun atau lebih. Beberapa ini memiliki asal-usul mereka dalam penelitian akademik sedangkan yang lain tumbuh dari metode yang dikembangkan oleh organisasi yang sangat proyek terfokus, sebagai konsultan contoh manajemen.

 

Masing-masing pendekatan memiliki cara sendiri dalam memandang proyek dan terminologi sendiri untuk dokumen dan proses yang membentuk manajemen proyek. Telah ada beberapa rasionalisasi dalam beberapa tahun terakhir, tetapi masih ada belasan metode banyak digunakan. Itu yang Anda paling mungkin untuk menemukan yang PMBOK ®, PRINCE2, Rantai Kritis, dan Agile.

PMBOK ® adalah singkatan Badan Manajemen Proyek Pengetahuan, yang menggambarkan proyek

praktek manajemen yang umum untuk 'sebagian besar proyek, sebagian besar waktu.' Itu PMBOK ® diterbitkan oleh Project Management Institute (PMI), yang dibentuk pada

Amerika Serikat pada tahun 1969. PMI juga menawarkan berbagai tingkat sertifikasi dan PMBOK ® adalah banyak digunakan dan dihormati.

PRINCE2 adalah pendekatan proses berbasis untuk manajemen proyek, menyediakan mudah metodologi disesuaikan dan scalable untuk pengelolaan semua jenis proyek. Itu Metode adalah standar untuk proyek-proyek sektor publik di Inggris dan dipraktekkan di seluruh dunia. Akronim berdiri untuk Proyek di Lingkungan Controlled dan ini adalah proyek Program manajemen yang saham lebih dari otoritas fungsional dan keuangan dengan manajemen senior, bukan hanya manajer proyek.

Metode Rantai Kritis tidak fundamental berbeda dari arus utama saat ini pendekatan tetapi berbeda dalam cara yang menangani risiko dan contingency.

Definisi Manajemen Proyek

Sebelum tentang diri kita sendiri dengan rincian dokumen manajemen proyek dan proses, itu adalah ideyang baik untuk mengambil langkah mundur dan berpikir tentang apa yang membuat sesuatu proyek dan mengapa perlu dikelola secara berbeda dari hari-hari kerja organisasi. Dengan kata lain, "Mengapa kita perlu manajemen proyek? '

Ada banyak definisi yang berbeda tentang apa yang merupakan proyek:

Proyek Project Management Institute-'A adalah usaha sementara dilakukan untuk menciptakan produk yang unik, layanan atau hasil. "

PRINCE2-'A Project adalah organisasi sementara yang dibuat untuk tujuan memberikan satu atau produk bisnis yang lebih sesuai dengan yang disepakati Kasus bisnis.'

Asosiasi untuk Manajemen Proyek (APM) - 'Sebuah usaha yang manusia material dan sumber daya keuangan diatur dalam cara baru untuk memberikan lingkup yang unik dari karya spesifikasi yang diberikan sering dalam batasan biaya dan waktu untuk mencapai perubahan yang bermanfaat didefinisikan oleh kuantitatif dan tujuan kualitatif. '

Manajemen H. Kerzner-'Project adalah perencanaan, pengorganisasian, memimpin dan mengendalikan sumber daya perusahaan untuk tujuan jangka pendek relatif yang telah dibentuk untuk menyelesaikan tujuan dan sasaran tertentu. Selanjutnya, manajemen proyek menggunakan sistem pendekatan manajemen yang memiliki tenaga fungsional (hirarki vertikal) ditugaskan untuk spesifik proyek (hirarki horizontal) '(2009).

Proyek memiliki beberapa atau semua karakteristik sebagai berikut:

● Mereka memiliki awal yang pasti dan endpoint

● Setelah titik akhir tercapai proyek ini lebih

● Mereka berusaha untuk mencapai sesuatu yang baru

Proyek manajemen mencakup hal-hal seperti: restrukturisasi organisasi, mempersiapkan pameran, mengembangkan sistem IT, meluncurkan kampanye pemasaran baru, kantor bergerak atau memang apapun tujuannya adalah untuk menghasilkan akhir yang todak didefinisikan sebagai item fisik.

Berbagai organisasi melakukan proyek jenis ini, termasuk: komersial perusahaan, departemen pemerintah, badan amal dan LSM (Lembaga Swadaya Masyarakat Organisasi), dan lainnya tidak-untuk organisasi nirlaba. Perbedaan antara ini jenis proyek adalah:

Penggunaan Staf Ahli

Proyek rekayasa hampir selalu mewakili hari-hari kerja organisasi. Sebagai contoh, sebuah perusahaan konstruksi akan mempekerjakan orang-orang yang mengkhususkan diri di kantor bangunan blok, bangunan umum, rumah, atau jalan.

Demikian pula, sebuah perusahaan manufaktur akan memiliki insinyur desain untuk mengambil produk dari konsepsi, melalui proses desain dan prototipe sebelum pekerjaan diserahkan untuk insinyur produksi yang kemudian akan bertanggung jawab untuk produksi massal. Ini sangat berbeda dari proyek manajemen di mana orang-orang yang biasanya tidak menjalankan proyek mungkin menemukan diri mereka melakukan banyak pekerjaan.

Isu yang berkaitan dengan lingkungan

Tantangan proyek rekayasa sering fisik di alam. Misalnya, proyek konstruksi dapat diadakan oleh cuaca buruk, penemuan arkeologi tetap, atau masalah lingkungan yang tak terduga lainnya. Proyek manajemen di sisi lain biasanya berlangsung pada organisasi sendiri tempat dan tidak tunduk pada isu.

Spesifikasi Akhir Deliverable

Dalam kasus proyek rekayasa deliverable akhir biasanya ditentukan secara rinci awal proyek karena akan perlu mematuhi standar yang ada atau undang-undang. Jika penyampaian merupakan bagian mekanik atau elektronik maka akan harus sesuai dengan sisa produk jadi.

Hal ini tidak biasanya terjadi dengan proyek manajemen di mana bentuk yang tepat dari final penyampaian mungkin tidak menjadi jelas sampai beberapa pekerjaan proyek telah dilakukan. Hal ini juga dapat mengubah sebagai proyek berkembang, atau dalam menanggapi riset pasar atau perkembangan lainnya.

Manajemen Proyek Perspektif

Manajemen proyek adalah disiplin perencanaan, pengorganisasian, memotivasi, dan mengendalikan sumber daya untuk mencapai tujuan tertentu. Sebuah proyek adalah usaha sementara yang dirancang untuk menghasilkan produk yang unik, layanan atau hasil dengan awal pasti dan akhir (biasanya dibatasi-waktu, dan sering terkendala oleh pendanaan atau kiriman), dilakukan untuk memenuhi tujuan dan sasaran yang unik, biasanya untuk membawa perubahan yang bermanfaat atau nilai tambah.

Tantangan utama dari manajemen proyek adalah untuk mencapai semua tujuan proyek dan tujuan sementara menghormati kendala pada lingkup, waktu, kualitas dan biaya. proyek perlu untuk dikelola untuk memenuhi tujuan mereka, yang didefinisikan dalam hal harapan waktu, biaya, dan kualitas.

Misalnya, Proyek Luang Lingkup, untuk memindahkan kantor pusat organisasi ke lokasi lain.

Persyaratan adalah:

Waktu              : Lengkap dengan Maret 2017

Kualitas           : Minimalkan gangguan produktivitas

Biaya               : Tidak menghabiskan lebih dari $ 125.000

Ruang lingkup proyek didefinisikan sebagai: 'totalitas keluaran, hasil, dan manfaat dan pekerjaan yang diperlukan untuk menghasilkan mereka '.

Ini dapat berubah dari waktu ke waktu, dan itu adalah tanggung jawab manajer proyek untuk memastikan proyek masih akan memberikan manfaat yang ditetapkan. Akibatnya, seorang manajer proyek harus mempertahankan fokus pada prioritas relatif dari waktu, biaya, dan kualitas dengan mengacu pada lingkup proyek.

Lembaga Manajemen Proyek (PMI) mendefinisikan manajemen proyek berikut ini

cara:

'Manajemen proyek adalah penerapan pengetahuan, keterampilan, peralatan, dan

teknik untuk memenuhi persyaratan proyek. '

Definisi ini menimbulkan pertanyaan 'Apa yang pengetahuan, keterampilan, peralatan, dan teknik akan saya butuhkan untuk berhasil mengelola proyek? ' Untuk menjawab pertanyaan ini, akan sangat membantu untuk melihat manajemen proyek dari tiga perspektif yang berbeda.

1.         Bagaimana proyek cocok dengan organisasi - ini mengacu pada kedua proyek dan individu-individu yang akan terlibat di dalamnya, termasuk bagaimana tanggung jawab mereka didefinisikan dan bagaimana mereka berinteraksi satu sama lain.

2.         Bagaimana proyek akan berkembang dari waktu ke waktu-ini disebut sebagai hidup proyek siklus dan urutan kronologis dari kegiatan yang perlu terjadi agar untuk memberikan proyek. Apapun perbedaan mereka, semua proyek akan dengan definisi berbagi siklus hidup yang sama; mereka semua akan memiliki awal, tengah, dan akhir.

3.         Keterampilan apa yang diperlukan untuk berhasil mengelola proyek-ini biasanya disebut sebagai 'Project Area Fungsional' karena ada daerah diskrit dalam manajemen proyek yang dapat dipertimbangkan dalam isolasi meskipun mereka sangat bergantung.

Organisasi proyek & Struktur

Cara di mana sebuah organisasi terstruktur sebagian besar merupakan hasil dari apakah hari-ke-hari kerja adalah didorong proses atau didorong proyek.

Proyek Fokus

Kerja organisasi 'ini sehari-hari melibatkan memberikan proyek-proyek yang unik untuk eksternal pelanggan untuk jangka waktu yang ditetapkan. Struktur manajemen mereka dirancang untuk mendukung proyek dan semua orang yang bekerja dalam organisasi yang ditugaskan untuk satu atau lebih proyek.

Contohnya termasuk: perusahaan konstruksi, organisasi consulting, pengembang software, dan biro iklan.

Read More

MODEL-MODEL PROSES PERANGKAT LUNAK

1. THE SPIRAL MODEL.

Model spiral adalah sebuah perangkat lunak model proses evolusi yang sifat iteratif sama seperti prototipe dengan aspek dikendalikan dan sistematis dari waterfall model. Ini memberikan potensi perkembangan pesat dari versi yang semakin lebih lengkap dari perangkat lunak.

Dengan menggunakan model spiral, perangkat lunak yang dikembangkan dalam serangkaian rilis perubahan. Selama iterasi awal, rilis mungkin akan sebuah model atau prototipe. Iterasi kemudian, versi yang semakin lebih lengkap dari sistem rekayasa.

(1.1)

Untuk ilustrasi, saya menggunakan kegiatan kerangka kerja umum dibahas sebelumnya. Setiap kegiatan kerangka merupakan salah satu segmen dari jalur spiral diilustrasikan pada Gambar 2.7. Sebagai proses evolusi ini dimulai, tim perangkat lunak yang melakukan kegiatan yang tersirat oleh sirkuit sekitar spiral searah jarum jam, dimulai di pusat. Risiko (Bab 28) dianggap sebagai setiap putarannya dibuat. Jangkar titik pencapaian-gabungan dari produk dan kondisi kerja yang dicapai sepanjang jalur spiral-dicatat untuk setiap lulus evolusi.

Rangkaian pertama sekitar spiral mungkin mengakibatkan pengembangan spesifikasi produk; melewati berikutnya sekitar spiral dapat digunakan untuk mengembangkan prototipe dan versi kemudian semakin lebih canggih dari perangkat lunak ini. Setiap melewati hasil wilayah perencanaan penyesuaian dengan rencana proyek. Biaya dan jadwal disesuaikan berdasarkan umpan balik yang berasal dari pelanggan setelah ditawarkan.

Tidak seperti model proses lain yang berakhir ketika perangkat lunak yang disampaikan, model spiral dapat disesuaikan untuk menerapkan seluruh kehidupan perangkat lunak komputer. Oleh karena itu, rangkaian pertama sekitar spiral mungkin merupakan "proyek pengembangan konsep" yang dimulai pada inti spiral dan berlanjut selama beberapa iterasi sampai pengembangan konsep selesai. Jika konsep ini untuk dikembangkan menjadi produk yang sebenarnya, proses hasil luar pada spiral dan "rancangan pengembangan produk baru" dimulai. Produk baru akan berkembang melalui sejumlah iterasi sekitar spiral. Kemudian, sirkuit sekitar spiral dapat digunakan untuk mewakili "rancangan peningkatan produk." Pada intinya, spiral, ketika ditandai dengan cara ini, tetap operatif sampai perangkat lunak yang tersebut pensiun. Ada kalanya proses ini tidak aktif, tapi setiap kali perubahan dimulai, proses dimulai pada titik entri yang sesuai (misalnya, peningkatan produk).

Tapi seperti paradigma lainnya, model spiral bukanlah obat mujarab. Mungkin sulit untuk meyakinkan pelanggan (terutama dalam situasi kontrak) bahwa pendekatan evolusi dapat dikontrol. Hal ini menuntut keahlian penilaian risiko yang cukup besar dan bergantung pada keahlian ini untuk sukses. Jika risiko utama tidak ditemukan dan berhasil, masalah pasti akan terjadi.

2.      THE UNIFIED PROCESS

(1.2)

Tahap awal meliputi komunikasi pelanggan dan kegiatan perencanaan. Dengan bekerja sama dengan para pemangku kepentingan, kebutuhan bisnis untuk perangkat lunak diidentifikasi; arsitektur kasar untuk sistem ini diusulkan; dan rencana untuk, sifat inkremental iteratif proyek berikutnya dikembangkan. Kebutuhan bisnis mendasar dijelaskan melalui serangkaian kasus penggunaan awal yang menggambarkan fitur dan fungsi masing-masing kelas utama dari pengguna keinginan. Arsitektur pada saat ini tidak lebih dari garis tentatif subsistem utama dan fungsi dan fitur yang mengisi mereka. Kemudian, arsitektur akan disempurnakan dan diperluas menjadi satu set model yang akan mewakili pandangan yang berbeda dari sistem. Perencanaan sumber daya mengidentifikasi, menilai risiko utama, mendefinisikan jadwal, dan menetapkan dasar untuk fase yang akan diterapkan sebagai kenaikan software dikembangkan.

Fase elaborasi meliputi kegiatan komunikasi dan pemodelan model proses generik (Gambar 2.9). Elaborasi memurnikan dan memperluas kasus penggunaan awal yang dikembangkan sebagai bagian dari tahap awal dan memperluas representasi arsitektur mencakup lima pandangan yang berbeda dari perangkat lunak-model use case, model persyaratan, model desain, model pelaksanaan, dan model penyebaran. Dalam beberapa kasus, elaborasi menciptakan "dasar arsitektur executable" [Arl02] yang merupakan "potongan pertama" executable system. Baseline arsitektur menunjukkan kelayakan arsitektur tetapi tidak menyediakan semua fitur dan fungsi yang diperlukan untuk menggunakan sistem. Selain itu, rencana tersebut ditinjau pada puncak dari fase elaborasi untuk memastikan bahwa ruang lingkup, risiko, dan tanggal pengiriman tetap wajar. Modifikasi rencana sering dilakukan saat ini.

Tahap konstruksi identik dengan kegiatan konstruksi yang ditetapkan untuk proses software generik. Menggunakan model arsitektur sebagai input, tahap konstruksi mengembangkan atau mengakuisisi komponen perangkat lunak yang akan membuat setiap kasus penggunaan operasional bagi pengguna akhir. Untuk mencapai hal ini, persyaratan dan model desain yang dimulai selama fase elaborasi selesai untuk mencerminkan versi final dari kenaikan software. Semua fitur dan fungsi yang diperlukan dan dibutuhkan untuk peningkatan software (yaitu, rilis) yang kemudian diimplementasikan dalam kode sumber. Sebagai komponen sedang dilaksanakan, tes unit dirancang dan dilaksanakan untuk setiap. Selain itu, kegiatan integrasi (komponen perakitan dan pengujian integrasi) dilakukan. Gunakan kasus digunakan untuk menurunkan suite tes penerimaan yang dijalankan sebelum inisiasi tahap  berikutnya.

Fase transisi meliputi tahap terakhir dari kegiatan konstruksi generik dan bagian pertama dari penyebaran generik (pengiriman dan umpan balik) aktivitas. Software diberikan kepada pengguna akhir untuk pengujian beta dan umpan balik pengguna laporan baik cacat dan perubahan yang diperlukan. Selain itu, tim perangkat lunak menciptakan informasi dukungan yang diperlukan (misalnya, buku petunjuk, panduan troubleshooting, prosedur instalasi) yang diperlukan untuk rilis. Pada akhir fase transisi, selisih perangkat lunak menjadi rilis software yang dapat digunakan.

Tahap produksi bertepatan dengan kegiatan penyebaran proses generik. Selama fase ini, penggunaan berkelanjutan dari software ini dipantau, dukungan untuk lingkungan operasi (infrastruktur) yang disediakan, dan laporan cacat dan permintaan untuk perubahan diserahkan dan dievaluasi.

Sebuah alur kerja rekayasa perangkat lunak didistribusikan di seluruh fase. Dalam konteks, alur kerja adalah analog dengan seperangkat tugas (dijelaskan sebelumnya dalam bab ini). Artinya, alur kerja mengidentifikasi tugas-tugas yang diperlukan untuk mencapai suatu tindakan rekayasa perangkat lunak penting dan produk kerja yang dihasilkan sebagai konsekuensi dari berhasil menyelesaikan tugas. Perlu dicatat bahwa tidak setiap tugas diidentifikasi untuk alur kerja dilakukan untuk setiap proyek software. Tim menyesuaikan proses (tindakan, tugas, sub-tugas, dan produk kerja) untuk memenuhi kebutuhannya.

3.      THE WATERFALL MODEL

Model waterfall, kadang-kadang disebut siklus hidup klasik, menunjukkan sistematis,
Pendekatan sekuensial untuk pengembangan perangkat lunak yang diawali dengan spesifikasi pelanggan persyaratan dan berkembang melalui perencanaan, pemodelan, konstruksi, dan penyebaran, yang berpuncak pada dukungan yang berkelanjutan dari perangkat lunak selesai (Gambar 2.3).

(1.3)

Model waterfall adalah paradigma tertua untuk rekayasa perangkat lunak. Namun, selama tiga dekade terakhir, kritik model proses ini menyebabkan pendukung  untuk mempertanyakan kemanjurannya [Han95]. Di antara masalah yang kadang-kadang dihadapi saat model air terjun diterapkan adalah:

1.      proyek nyata jarang mengikuti aliran sekuensial menempatkan model tersebut diusulkan. Meskipun model linier bisa mengakomodasi iterasi, ia melakukannya secara tidak langsung. Akibatnya, perubahan dapat menyebabkan kebingungan sebagai hasil tim proyek.

2.      Biasanya sulit bagi pelanggan untuk menyatakan semua persyaratan secara jelas. Model waterfall membutuhkan ini dan memiliki kesulitan mengakomodasi ketidakpastian natural yang ada pada awal banyak proyek.

3.      Pelanggan harus memiliki kesabaran. Sebuah versi kerja dari program tidak akan tersedia sampai akhir dalam rentang waktu rancangan. Sebuah kesalahan besar, jika tanpa diketahui sampai program kerja ditinjau, bisa menjadi bencana.

Sekarang ini, kerja perangkat lunak yang serba cepat dan tergantung aliran perubahan yang tak pernah berakhir (untuk fitur, fungsi, dan isi informasi). Model waterfall ini sering tidak pantas untuk pekerjaan tersebut. Namun, dapat berfungsi sebagai model proses yang berguna dalam situasi di mana persyaratan tetap dan bekerja  untuk melanjutkan ke penyelesaian secara linear.

4.      PROTOTYPING

Seringkali, customer mendefinisikan satu set tujuan umum untuk perangkat lunak, tetapi tidak mengidentifikasi persyaratan rinci untuk fungsi dan fitur. Dalam kasus lain, pengembang mungkin tidak yakin efisiensi sebuah algoritma, adaptasi dari sistem operasi, atau bentuk interaksi manusia-mesin harus dilakukan. Dalam hal ini, dan beberapa situasi , paradigma prototyping mungkin menawarkan pendekatan yang terbaik.

Prototyping paradigma (Gambar 2.6) dimulai dengan komunikasi. Anda bertemu dengan pemangku kepentingan lainnya untuk menentukan tujuan keseluruhan untuk perangkat lunak, mengidentifikasi Kebutuhan apa saja yang diketahui, dan garis besar daerah di mana definisi lebih lanjut adalah wajib. Sebuah prototipe iterasi direncanakan cepat, dan pemodelan (dalam bentuk "desain cepat") terjadi. Sebuah desain cepat berfokus pada representasi dari aspek-aspek perangkat lunak yang akan terlihat oleh pengguna akhir (misalnya, tata letak interface atau tampilan output format manusia). Desain cepat mengarah ke pembangunan prototipe. Prototipe ini digunakan dan dievaluasi oleh pemangku kepentingan, yang memberikan umpan balik yang digunakan untuk lebih menyempurnakan Kebutuhan. Iterasi terjadi sebagai prototipe disetel untuk memenuhi kebutuhan berbagai pemangku kepentingan, sementara pada saat yang sama memungkinkan Anda untuk lebih memahami apa yang perlu dilakukan.

(1.4)

Idealnya, prototipe berfungsi sebagai sebuah mekanisme untuk mengidentifikasi kebutuhan perangkat lunak. Jika prototipenya yang akan dibangun, Anda dapat menggunakan fragmen program yang ada atau menerapkan alat-alat (misalnya, generator laporan dan window manager) yang memungkinkan program kerja yang akan dihasilkan dengan cepat.

Prototyping dapat menjadi masalah karena alasan berikut:

1.              Stakeholder melihat apa yang tampaknya menjadi kerja perangkat lunak, tidak menyadari bahwa prototipe diadakan secara asal saja, tidak menyadari bahwa terburu-buru untuk mengerti kerja kualitas perangkat lunak Anda secara keseluruhan atau kemampuan pemeliharaan jangka panjang. Ketika diberitahu bahwa produk harus dibangun kembali sehingga tingkat kualitas yang tinggi dapat dipertahankan, stakeholder mengaggapnya tidak adil dan menuntut yang "beberapa perbaikan" diterapkan untuk membuat prototipe produk bekerja. Sering kali, manajemen pengembangan perangkat lunak mengalah.

2.                 Sebagai seorang insinyur perangkat lunak, Anda sering membuat kompromi implementasi untuk mendapatkan prototipenya dengan cepat. Sebuah sistem operasi yang tidak pantas atau bahasa pemrograman dapat digunakan hanya karena ia tersedia dan dikenal; sebuah algoritma yang tidak efisien dapat diimplementasikan hanya untuk menunjukkan kemampuan. Setelah beberapa saat, Anda mungkin merasa nyaman dengan pilihan ini dan melupakan semua alasan mengapa mereka tidak pantas. Kurang dari ideal pilihan sekarang telah menjadi bagian utuh dari sistem.’

Meskipun masalah dapat terjadi, prototipe dapat menjadi paradigma yang efektif untuk rekayasa perangkat lunak. Kuncinya adalah untuk menentukan aturan main di awal; yaitu, semua stakeholder harus setuju bahwa prototype dibangun untuk melayani sebagai mekanisme untuk mendefinisikan Kebutuhan. Hal ini kemudian akan dibuang (setidaknya sebagian), dan perangkat lunak aktual direkayasa dengan mata tertuju pada kualitas.

5.      V-MODEL

Salah satu variasi dalam representasi model air terjun yakni V-model yang diwakili dalam Gambar 1.5, V-Model [Buc99] menggambarkan hubungan tindakan jaminan kualitas terhadap tindakan yang terkait dengan komunikasi, pemodelan, dan kegiatan konstruksi awal. Sebagai tim software bergerak ke sisi kiri V, persyaratan masalah dasar yang disempurnakan menjadi representasi semakin lebih rinci dan teknis dari masalah dan solusinya. Setelah kode telah dihasilkan, tim bergerak naik sisi kanan V, pada dasarnya melakukan serangkaian tes (langkah jaminan mutu) yang memvalidasi masing-masing model dibuat sebagai tim pindah ke sisi kiri bawah. Pada kenyataannya, tidak ada perbedaan mendasar antara siklus hidup klasik dan model V-model. V-model yang menyediakan cara untuk memvisualisasikan bagaimana verifikasi dan validasi langkah yang diterapkan untuk pekerjaan rekayasa sebelumnya.

                                                           
                                                                (1.5)

sumber: Pressman, Roger s. 2010. software engineering 7th edition

Read More