Tersedia online di www.sciencedirect.

com
2212-8271 2017 Penulis. Diterbitkan oleh Elsevier Ini adalah sebuah artikel akses terbuka di bawah CC BY-NC-ND lisensi
(http://creativecommons.org/licenses/by-nc-nd/4.0/). Peer-review di bawah tanggung jawab komite ilmiah dari 27 CIRP Desain
Konferensi doi: 10,1016 / j.procir.2017.02.018

ScienceDirect
Procedia CIRP 60 (2017) 422-427
27 CIRP Desain 2017

Bridging di lokasi Praktek dan Prinsip Desain untuk Service pembangunan

Shigeru Hosonoa *, Yoshiki Shimomuraa
aTokyo Metropolitan University, 6-6 Asahigaoka, Hino, Tokyo 191-0065, Jepang
* Sesuai penulis. Tel .: + 81-42-585-8611. Alamat E-mail: s-hosono@tmu.ac.jp
Abstrak
Pentingnya kerjasama antara pengembang dan operator telah meningkat melalui siklus hidup layanan, karena mereka diharapkan
untuk mengeksplorasi nyeri klien mereka dan co-menciptakan sistem ICT baru untuk peluang bisnis mereka melalui sejumlah uji
coba. Namun, pengembangan tangkas seperti telah menyebabkan konflik dengan manajemen pembangunan konvensional, yang
mengasumsikan pembangunan air terjun. Proses pembangunan ini diadministrasikan oleh kemajuan dokumen status, seperti
menciptakan, Ulasan, diperbarui, dan diselesaikan, di situs pembangunan. Makalah ini memperkenalkan sebuah model dokumen-
perhatian-desain untuk menunjukkan pengembang tugas terkait untuk memperbarui bagian tertentu dari dokumen selama
pekerjaan berulang-ulang mereka antara pembangunan dan operasi. Model ini menggabungkan tiga domain - dokumen proses
pemeriksaan, kepedulian, dan prinsip desain - dengan menghubungkan mereka satu-per-satu dan membentuk struktur tunggal.
Prosedur ini memungkinkan untuk beradaptasi setiap on-site aturan lokal desain dan pengembangan. Oleh karena itu, sistem
dapat diperkenalkan ke situs setiap pengembang dengan biaya adaptasi sedikit. Kemudian, mekanisme ini dapat mempercepat
berbagai kegiatan kolaborasi antara pengembang dan operator dan membimbing kiriman mereka. 2017 2017 The Authors.
Penulis. Diterbitkan Diterbitkan oleh Elsevier oleh Elsevier BV Ini
adalah sebuah artikel akses terbuka di bawah CC BY-NC-ND lisensi
(http://creativecommons.org/licenses/by-nc-nd/4.0/). Peer-review di bawah tanggung jawab komite ilmiah dari 27 CIRP Desain
Conference. Peer-review di bawah tanggung jawab komite ilmiah dari 27 CIRP Desain Konferensi
Kata kunci: DevOps (pengembangan dan pengoperasian); prinsip desain; kolaborasi; kekhawatiran; tugas
1. Pendahuluan
ICT (teknologi informasi dan komunikasi) penyedia layanan telah menyediakan layanan integrasi sistem untuk klien mereka.
Sistem insinyur menerapkan komponen perangkat lunak, membangun sistem ICT infrastruktur on-premise dengan produk
perangkat keras, dan mendukung masalah sistem ICT dalam operasi. Klien mengharapkan tingkat tinggi kesempurnaan fungsi
infrastruktur sistem ICT sebagai hasil dari layanan integrasi. Namun, harapan mereka telah berubah dari implementasi dan integrasi
pengalaman berharga melalui ICT layanan siklus hidup, seperti infrastruktur tersebut dapat dengan mudah diintegrasikan dengan
Gambar 1 Cloud layanan[1]:.
perangkat lunak dan perangkat keras fungsi dari layanan awan Infrastruktur sebagai layanan (IaaS), Platform sebagai layanan
(PaaS) dan perangkat lunak sebagai layanan (SaaS) (Gambar 1).
Sementara sejumlah layanan cloud tersebut telah dipasarkan, sistem insinyur didesak untuk memperpanjang peran mereka dari
kalangan menengah ke awal dan kemudian fase siklus hidup layanan; merancang sistem layanan konseptual dan meningkatkan
layanan bagi generasi berikutnya (Gbr.2). Fase ini membutuhkan praktek terus menerus hipotesis dan verifikasi untuk mengangkat
baru-baru ini muncul bisnis dan teknis kendala. Namun, proses ini dapat didamaikan dengan manajemen proses pembangunan air
terjun, yang digunakan secara luas dalam bisnis.
Peran praktisi Gbr.2 Service melalui siklus hidup
423 Shigeru Hosono dan Yoshiki Shimomura / Procedia CIRP 60 (2017) 422-427
Praktik terus menerus akan bolak-balik. Misalnya, posisi kemajuan pembangunan akan kembali ke fase sebelumnya ketika
merevisi spesifikasi menjadi keharusan setelah evaluasi prototipe. Pekerjaan berulang tersebut dapat dilakukan dengan sekelompok
pengembang dan operator. Co-kreatif mereka kegiatan dan budaya telah menjadi signifikan, dan dilambangkan sebagai 'DevOps'
[2-3]. Namun, kemajuan berulang dan bertahap ini bekerjasama sulit untuk Administrasi di bawah cara konvensional manajemen
proyek, yang mengasumsikan bahwa kemajuan pembangunan harus mengikuti model air terjun.
Kemajuan proyek biasanya dipantau oleh penyelesaian tugas-tugas dalam tugas terstruktur diatur yaitu kerja-breakdown-struktur
(WBS), dan oleh tonggak yang menentukan tinjauan dokumen dan persetujuan. Namun, prosedur tidak fleksibel tersebut tidak
dapat berlaku untuk situs pembangunan seperti itu. Adaptasi kerja dengan memodifikasi dan meluruskan kembali WBS standar
mahal bagi mereka. Oleh karena itu, sangat mendesak untuk menyediakan mekanisme untuk pengembang, operator dan
administrator untuk tugas dan pengendalian dokumen.
2. Terkait Kerja
2.1. Manajemen siklus hidup untuk Infrastruktur TIKJasa
manajemensiklus hidup pendekatan untuk layanan infrastruktur ICT telah disajikan praktik terbaik pelayanan dan
mendiskusikan bagaimana pengembangan layanan dan fase operasi dapat dirampingkan dan apa menargetkan praktisi layanan
harus mengejar di setiap fase. ITIL (IT Infrastructure Library) [4], COBIT (tujuan Control untuk informasi dan teknologi yang
terkait) [5], dan IT4IT (IT untuk IT) [6] adalah kerangka kerja manajemen siklus hidup untuk layanan ICT, meskipun kiriman
mereka timbul dari perbedaan dalam sudut manajemen.
2.2. ITIL
ITIL adalah serangkaian dokumen, yang digunakan untuk membantu pelaksanaan kerangka siklus hidup untuk IT (teknologi
informasi) manajemen pelayanan. Kerangka disesuaikan ini mendefinisikan bagaimana manajemen layanan diterapkan dalam
sebuah organisasi. Hal ini juga selaras dengan standar internasional, ISO 20000 [7]. ITIL diatur dalam serangkaian lima unsur:
strategi pelayanan, desain layanan, layanan transisi, operasi pelayanan dan peningkatan pelayanan yang terus-menerus. Unsur-
unsur ini pada gilirannya menggambarkan sistem umpan balik loop tertutup, yang memberikan umpan balik semua tahapan siklus
hidup. Buku-buku ITIL untuk setiap elemen memberikan praktik terbaik dan disiplin di belakang mereka untuk menyediakan
layanan ICT secara efektif; demikian ITIL tidak memberikan tugas atau prosedur beton. Mereka berada dalam tangan kebijaksanaan
interpretasi individu praktisi.
2.3. COBIT
COBIT adalah kerangka kerja tata kelola TIK dan toolset pendukung, yang memungkinkan manajer untuk menjembatani
kesenjangan antara kebutuhan kontrol, masalah teknis dan risiko bisnis. COBIT memungkinkan pengembangan kebijakan yang
jelas dan praktik yang baik untuk kontrol ICT di seluruh organisasi. COBIT menekankan
kepatuhan terhadap peraturan, membantu organisasi untuk meningkatkan nilai diperoleh dari ICT, memungkinkan keselarasan dan
menyederhanakan pelaksanaan tata kelola TIK dan kontrol kerangka perusahaan. COBIT mengacu pada organisasi, meskipun tidak
memberikan banyak pemikiran untuk tindakan individu dalam organisasi.
2.4. IT4IT
IT4IT mendefinisikan standar arsitektur referensi, yang terdiri dari arsitektur referensi dan model operasi berbasis rantai-nilai
untuk mengelola bisnis teknologi informasi. Sebuah rantai nilai adalah serangkaian kegiatan yang organisasi melakukan untuk
memberikan produk dan layanan yang berharga. Sementara produk melewati kegiatan rantai dalam rangka, produk memperoleh
nilai pada setiap kegiatan. Memperkenalkan kerangka rantai nilai ini untuk penyedia ICT akan membantu mengidentifikasi kegiatan
yang sangat penting untuk kemajuan strategi dan pencapaian tujuan.
Rantai nilai dikelompokkan menjadi dua kategori utama dari kegiatan: (1) kegiatan utama, yang prihatin dengan produksi atau
pengiriman barang / jasa, dan kegiatan (2) mendukung, yang memfasilitasi efisiensi dan efektivitas kegiatan utama.
Standar IT4IT memecah rantai nilai menjadi empat value stream untuk membantu adoptability dari arsitektur referensi IT4IT.
Setiap value stream merupakan wilayah kunci dari nilai yang ICT menyediakan siklus hidup layanan yang komprehensif. Empat
nilai utama stream adalah (1) strategi untuk portofolio, (2) kebutuhan untuk menyebarkan, (3) permintaan untuk memenuhi, dan
(4) mendeteksi untuk memperbaiki. Nilai aliran utama untuk rantai nilai TIK umumnya menyelaraskan dengan apa ICT tradisional
panggilan rencana, membangun, memberikan, dan menjalankan. Bila digunakan dengan model berbasis rantai nilai TIK, ini
ditransformasikan ke dalam rencana, sumber, tawaran, dan mengelola. Nilai sungai-sungai ini memiliki peran penting dalam
membantu holistik menjalankan siklus hidup seluruh layanan.
Dengan cara ini, IT4IT meneliti kegiatan melalui siklus hidup. Namun, pembahasan tentang kegiatan masing-masing value
stream adalah abstrak dan masih adanya kesenjangan pada praktik di situs pengembangan, di mana manajemen proyek berbasis
dokumen-diharapkan.
Seperti yang diamati di atas, pekerjaan sebelumnya tidak menggambarkan praktek-praktek yang nyata tetapi menunjukkan
praktek yang ideal yang harus diikuti melalui siklus hidup. Oleh karena itu, praktisi layanan harus menjembatani kesenjangan
antara manajemen proyek konvensional dan kerangka kerja dengan interpretasi dan pengalaman mereka.
3. Membimbing Platform untuk DevOps Praktek
3.1. Dokumen, Kepedulian dan Prinsip Desain
Untuk memberikan mekanisme tentang cara mengontrol tugas dan dokumen untuk pengembang, operator dan administrator,
penulis fokus pada hubungan antara dokumen, tugas dari keprihatinan dan prinsip-prinsip desain.
Manajemen proyek berbasis dokumen mengarah langsung ke kontrol kualitas layanan. Dokumen pengembangan dikembangkan
dan dikaji oleh para praktisi dan manajer,
424 Shigeru Hosono dan Yoshiki Shimomura / Procedia CIRP 60 (2017) 422 427
-.Gambar 3. Struktur antara praktek-praktek pembangunan di lokasi dan prinsip-prinsip desain.
mengikuti praktik konvensional di lokasi pembangunan, yang secara lokal ditetapkan dan dilakukan. Prosedur yang terstruktur
dengan tugas-tugas praktisi.
Tugas dalam pembangunan seperti persyaratan mendefinisikan, spesifikasi, dan uji kasus, ditetapkan peran praktisi, misalnya
desain, membangun, pengiriman, dukungan. Tugas-tugas yang tidak selalu dilakukan oleh praktisi tetapi melalui kerja kolaboratif
dengan praktisi lain, yang memiliki peran lainnya. Kerja kolaboratif ini bisa bolak-balik, sementara itu membuat kemajuan secara
bertahap menuju fase berikutnya. Posisi tugas berulang dalam proses siklus hidup dapat divisualisasikan ketika status pembangunan
digambarkan dan dipetakan ke aliran prinsip-prinsip desain (Gbr.3).
Bagian berikut menjelaskan lapisan Gbr.3: prinsip-prinsip desain, tugas dan review dokumen, dan bagaimana lapisan dapat
diintegrasikan ke dalam struktur tunggal.
3.2. Prinsip desain
Lapisan bawah ini didasarkan pada prinsip-prinsip desain desain pendekatan -Axiomatic, yang abstrak proses desain dengan
transisi dari parameter desain antara empat domain [8]. Atribut pelanggan (CA) ditranskripsikan menjadi kebutuhan fungsional
(FR). Persyaratan fungsional (FR) ditranskripsikan menjadi parameter desain (DP). Parameter desain ditranskripsikan menjadi
variabel proses (PV). Prinsip ini desain memberikan analisa fundamental dan proses sintesis dalam desain, dan mereka dapat
dipetakan ke proses pembangunan dalam praktek dan diwakili dengan nama-nama mereka dari fase: observasi, definisi persyaratan,
fungsional desain, implementasi, pengujian, operasi dan perbaikan.
3.3. Kekhawatiran dan Tugas Praktisi
Layananlapisan tengah adalah tentang keprihatinan dan tugas. Tugas didefinisikan oleh peran dalam fase pengembangan layanan
dan operasi, dan tugas-tugas dapat dikategorikan oleh kekhawatiran utama dalam peran. Sebagai contoh, analis menyelidiki tujuan
klien dalam bisnis dan hambatan untuk mengejar mereka. Konsultan mengidentifikasi tuntutan klien dan menetapkan persyaratan
untuk solusi.
Desainer mendefinisikan spesifikasi fungsional berikut persyaratan. Pelaksana mengembangkan komponen perangkat lunak dan
mengintegrasikan mereka dengan perangkat keras dan perangkat lunak untuk bekerja. Mereka juga menentukan spesifikasi tes dan
melakukan mereka. Tugas prioritas ini praktisi berubah sementara hasil pembangunan dan juga fokus mereka pada kekhawatiran
akan bergeser.
3.4. Dokumen Ulasan Proses
Lapisan atas adalah tentang praktek, yang dilakukan di bawah aturan bisnis individu dan bea cukai di situs pembangunan. Setiap
situs pembangunan telah ditetapkan tugas standar pembangunan. Tugas-tugas yang definisi kebutuhan, desain fungsional, prosedur
operasional, kode sumber. Dalam kebanyakan kasus kiriman dilaporkan oleh dokumen, yang ditinjau oleh administrator atau
manajer proyek. Proses pembangunan dan ulasan ini telah diadopsi di bawah skema manajemen proyek mereka.
3.5. Dokumen-Kepedulian-Desain Model
Dokumen, keprihatinan dan prinsip-prinsip desain pada bagian sebelumnya adalah konsep independen, meskipun merenungkan
tujuan mereka memungkinkan kita untuk membuat hubungan yang sesuai. Tugas untuk dokumen memperbarui dapat diidentifikasi
oleh posisi dari proses desain. Hubungan ini dapat diperoleh dengan menghubungkan dokumen dengan domain desain melalui
tugas praktisi.
Bagian desain mewakili prinsip desain, yang terdiri dari permintaan, fungsi, struktur dan variabel. Hubungan antara mereka
mewakili transkripsi atribut, parameter atau variabel antara fase desain seperti persyaratan untuk fungsi dan fungsi untuk variabel.
Bagian kepedulian merupakan keprihatinan praktisi, yang terdiri dari kelompok negara. Mereka terdiri dari tugas-tugas, yang dapat
dikategorikan di situs pengembangan di mana aturan pembangunan daerah dan prosedur telah dilakukan. Akibatnya, tiga domain
- prinsip desain, kepedulian dan proses review dokumen - digabungkan dengan hubungan antara mereka dan dibentuk menjadi
struktur tunggal.
425 Shigeru Hosono dan Yoshiki Shimomura / Procedia CIRP 60 (2017) 422-427
Dengan cara ini, prinsip desain, kepedulian dan review dokumen proses yang terstruktur (Gbr.4).
Gambar. Model 4. Dokumen-perhatian-desain.
4. Pelaksanaan
4.1. Standarisasi Kekhawatiran dan Tugas
Untuk menerapkan model dokumen-perhatian-desain, pendekatan dalam rekayasa perangkat lunak membantu untuk
memberikan bentuk konkret dari kekhawatiran dan tugas. Pendekatan - SEMAT (Software Metode Teknik dan Teori) visualisasi
kemajuan berulang seperti dan tindakan selanjutnya yang cepat bagi para praktisi [9- 12]. SEMAT mendefinisikan kernel untuk
membuat esensi dari beton pengembangan perangkat lunak tangkas dan untuk mengidentifikasi bidang usaha perangkat lunak yang
tim pengembangan harus memperhatikan dan menilai kemajuan dan kesehatan. Kernel terdiri dari tiga bidang diskrit keprihatinan;
'pelanggan', 'solusi' dan 'usaha'. The 'kekhawatiran' tentang pelanggan termasuk segala sesuatu yang berkaitan dengan penggunaan
aktual dan eksploitasi dari sistem perangkat lunak yang akan diproduksi. Kekhawatiran tentang solusi terdiri segala sesuatu yang
berhubungan dengan spesifikasi dan pengembangan sistem perangkat lunak. Kekhawatiran tentang usaha mencakup segala sesuatu
terkait dengan tim pengembangan dan cara mereka melakukan pekerjaan mereka. Setiap bidang perhatian terdiri dari 'Alpha'
(abstrak tingkat kemajuan atribut kesehatan) untuk memahami, memantau, dan kontrol langsung untuk kemajuan dan kesehatan
usaha. SEMAT Kernel menyediakan Alpha dasar: 'kesempatan', 'stakeholder', 'persyaratan', 'sistem software', 'tim', 'bekerja', dan
'cara kerja'. Setiap alpha menetapkan negara dan checklist untuk membantu para profesional memahami kemajuan dan kesehatan
pengembangan perangkat lunak.
Cara mendefinisikan masalah dan tugas mereka kernel SEMAT dapat diterapkan untuk menentukan bahwa model desain
dokumen-concern-. Item kekhawatiran dapat diperoleh dari IT4IT karena menetapkan kegiatan utama dalam hal proposisi nilai
melalui siklus hidup. Kegiatan didefinisikan dalam Nilai Streaming kekhawatiran dari partisi: (1) strategi untuk portofolio, (2)
permintaan untuk menyebarkan, (3) permintaan untuk memenuhi, dan (4) mendeteksi untuk memperbaiki. Setiap keprihatinan
terdiri dari empat negara, dan setiap negara dapat dicapai dengan satu set tugas.
Berikut ini menunjukkan kekhawatiran, negara, dan tugas-tugas (Lampiran Table1).
(1) Kepedulian: Strategi Portfolio (S2P) value stream (a) Negara: Strategi ditentukan.
Tugas: menentukan tujuan; menyelaraskan bisnis dan TI peta jalan;
dan menetapkan standar dan kebijakan (b) Negara: Jasa Portofolio didirikan.
Tugas: mendefinisikan arsitektur enterprise; merasionalisasilayanan;
portofolio dan menciptakan layanan cetak biru dan peta jalan (c) Negara: Permintaan diekstrak.
Tugas: mengkonsolidasikan permintaan; dan menganalisis prioritas (d) Negara: Seleksi selesai.
Tugas: nilai bisnis; risiko; biaya; manfaat dan sumber daya;
apa-jika analisis; dan memastikan tata kelola
(2) Kepedulian: Permintaan untuk Menyebarkan (R2D) Value Stream (a) Negara: Rencana dan Pengiriman
Tugas: proyek TI rencana; model layanan logis; Persyaratan; dan fungsional dan teknis; dan standar dan kebijakan (b)
Negara:Pengembangan:
Tugas pengembangan tangkas; berulang; dan air terjun (c) Negara: Uji
Tugas: fungsional (desktop, web, mobile); kinerja
(desktop, web, mobile); dan keamanan (statis, dinamis) (d) Negara: Deployment
Tugas: rencana rilis; berubah dan proses konfigurasi;
manajemen pengetahuan; dan aplikasi dan keamanan monitor
(3) Kepedulian: Permintaan untuk Penuhi (R2F) Value Stream (a) Negara: Desain dan Publikasikan
Tugas: item dalam katalog tumbuk dari semua mesin pemenuhan; mengatur pilihan harga dan SLA; dan mempublikasikan
layanan (b) Negara: Langganan
Tugas: keterlibatan Portal; Pengalaman pribadi;diri;
 layanan dan mengelola langganan (c) Negara: Memenuhi
Tugas: fulfilments rute; mengotomatisasi penyebaran; menggunakaninternal
penyediadan eksternal; dan mengintegrasikan dengan sistem perubahan aset dan konfigurasi (d) Negara: Mengukur
Tugas: layanan manajemen penggunaan; tolak / show kembali;
biaya transparansi; dan survei dan penilaian
(4) Kepedulian: Mendeteksi ke Koreksi (D2C) Value Stream (a) Negara: Mendeteksi
Tugas: melihat peristiwa; alarm; dan metrik di seluruh
infrastruktur (b) Negara: Mendiagnosa
Tugas: pengayaan; akar masalah; keparahan dan bisnis
dampak; yang telah ditentukan jalur eskalasi; dan auto-memperbaiki umum Negara masalah (c): Perubahan
Tugas: mendefinisikan permintaan perubahan; dan melakukan masalah danrisiko
analisis(d) Negara: Selesaikan
Tugas: melaksanakan perubahan; Leverage menjalankan buku; memverifikasi
pemulihan; dan catatan dekat
426 Shigeru Hosono dan Yoshiki Shimomura / Procedia CIRP 60 (2017) 422-427
4.2. Alat Manajemen
Tugaskekhawatiran standar dan tugas dapat dikelola oleh alat manajemen tugas, yang juga memonitor status dokumen
pembangunan. Gambar. 5 menunjukkan arsitektur prototipe. Ini terdiri dari sebuah 'masukan' modul proses pembangunan, sebuah
'ekstrak' modul tonggak dokumen, sebuah 'ekstrak' modul tugas, sebuah 'masukan' modul desain contoh, database prinsip-prinsip
desain, desain contoh database, tugas database, 'ekstrak' modul tugas dipengaruhi, modul manajemen kemajuan, dan modul
penampil.
Gambar. 5 Arsitektur alat manajemen tugas.
4.3. Studi Kasus
Untuk memvalidasi model dokumen-perhatian-desain, alat tersebut telah diterapkan pada tahap desain pengembangan pelayanan
kesehatan. Target pengguna dari layanan ini adalah orang-orang bisnis paruh baya, yang selalu sibuk dalam karyanya. Para
pengguna ingin menjadi sehat, dan mengurangi risiko memiliki penyakit yang berhubungan dengan kebiasaan gaya hidup mereka,
seperti minum sehari-hari. Mereka juga ingin mengetahui hasil dari upaya mereka segera.
Versi pertama dari layanan ini dirancang bekerja sama dengan pelayanan kesehatan. Setelah melanjutkan ke desain rinci, para
desainer Ulasan struktur dari desain sistem pelayanan. Mereka memutuskan untuk mengubah pengiriman catatan kesehatan tidak
dari perusahaan kesehatan tetapi dari penyedia layanan ICT. Revisi ini pilihan desain sistem tidak mempengaruhi fungsi penyediaan
data kesehatan; tidak ada yang berubah dari sisi pengguna. Dengan demikian, pengerjaan ulang desain harus dibatasi, sehingga
menghindari pengerjaan ulang dari semua pekerjaan dokumentasi.
Gambar. 6 Mengidentifikasi dipengaruhi bagian dari dokumen.
Saat melakukan peninjauan kembali desain ini, spesifikasi fungsional diperbarui dan obyek terkait diidentifikasi. Dokumen
spesifikasi fungsional dan dokumen spesifikasi fungsional rinci diindikasikan untuk pembaruan. Bagian dari dokumen tersebut
ditentukan oleh hubungan antara lapisan (Gambar. 6).
5.
Diskusilink dari tugas untuk dokumen yang ditetapkan untuk proses pembangunan di lokasi studi kasus. Daftar tugas (Lampiran
Table.1) digunakan sebagai standar, karena itu desainer harus memastikan bahwa itu adalah lengkap untuk mencakup semua tugas-
tugas yang diperlukan. Sementara itu, dokumen, yang format dan langkah-langkah meninjau berbeda di setiap lokasi
pengembangan, terkait dengan tugas-tugas sesuai dengan prosedur pembangunan mereka. Satu- per-satu linkage ini untuk
pengembangan memungkinkan untuk beradaptasi berbagai proses dokumen-base (Gbr. 7). Oleh karena itu, sistem dapat
diperkenalkan ke situs manapun pengembang lokal dengan biaya adaptasi sedikit. Kemudian, situs pengembangan layanan dapat
memperkenalkan mekanisme ini ke dalam sistem manajemen tugas / proyek mereka dengan mudah, dan mempercepat berbagai
kegiatan kolaborasi antara pengembang dan operator dan membimbing kiriman mereka.
Gambar. 7 Beradaptasi dengan on-site review dokumen praktek
6. Kesimpulan
Munculnya awan lingkungan telah mendorong pengembang dan operator untuk memiliki hubungan dekat dan memberikan
layanan web cloud-enabled lagi dan lagi untuk memenuhi kebutuhan klien mereka. Namun, manajemen pembangunan air terjun
konvensional tidak cocok bekerja berulang tersebut. Untuk mengisi kesenjangan, artikel ini menyajikan model keprihatinan-desain
document-, yang memungkinkan untuk mengidentifikasi tugas-tugas untuk dokumentasi. Pendekatan ini dapat mencakup semua
tahapan melalui siklus hidup dan membantu kerja kolaboratif antara praktisi yang memiliki peran yang berbeda. Selain itu, ini satu
satu-demi-langkah menghubungkan memungkinkan untuk beradaptasi setiap aturan di tempat yang ditentukan secara lokal untuk
mengelola proses pembangunan mereka. Oleh karena itu, sistem dapat diperkenalkan ke situs setiap pengembang dengan biaya
adaptasi sedikit. Kemudian, mekanisme ini dapat mempercepat berbagai kegiatan kolaborasi antara pengembang dan operator dan
membimbing kiriman mereka.
427 Shigeru Hosono dan Yoshiki Shimomura / Procedia CIRP 60 (2017) 422-427
Referensi
[1] Ambrust, M., Fox, A., Griffith, R., Joseph, A., Katz, R., Konwinski, A., Lee, G., Patterson, D. Rabkin, A., Stoica I. dan
Zahaira, M. 'di atas awan: a Berkeley pandangan komputasi awan' yang tersedia di http://www.eecs.berkeley.edu/Pubs/ TechRpts
/ 2009 / EECS-2009-28.pdf (diakses pada 1 September 2016) [2] Haight, C., 'DevOps: lahir di awan dan datang ke perusahaan',
Gartner Research, ID Number: G00208163 2010. [3] Haight, C., 'DevOps: sifat perubahan sistem administrasi',
Gartner Research, ID Number: G00211703, 2011. [4] ITIL, tersedia di http://www.itil.org.uk/ (diakses pada 1 September
2016) [5] COBIT, tersedia di https://cobitonline.isaca.org/ (diakses pada 1 September
2016) [6] IT4IT, tersedia di http://www.opengroup.org/IT4IT (diakses pada 1
September 2016)
[7] ISO20000, tersedia di http://www.iso.org/iso/home/store/catalogue_tc/ catalogue_tc_browse.htm0? commid = 5.013.818 (acc
essed pada 1 September 2016) [8] Suh, NP .: aksiomatik Desain, Oxford University Press, Oxford, 2001. [9] Jacobson, I., Ng,
PW, McMahon, P., Spence, I., Lidman, S ., The Essence of Software Engineering: Menerapkan SEMAT Kernel, Addison-
Wesley; 2013. [10] Jacobson, I., Huang, S., Kajko-Mattsson, M., McMahon, P., Seymour, E., SEMAT: Tiga Tahun Visi,
Pemrograman dan Perangkat Lunak Komputer 38: 1; 2012, p. 1-12. [11] Objek Management Group (OMG), Dokumen Terkait
Dengan Essence - Kernel Dan Bahasa Untuk Rekayasa Perangkat Lunak Metode 1.0 - Beta 1; 2013,
http://www.omg.org/spec/Essence/1.0/Beta1/PDF. [12] K. Muto, K. Kimita, H. Tanaka, E. Numata, S. Hosono, S. Izukura, T.
Sakaki dan Y. Shimomura: Sebuah Metode Manajemen Tugas untuk Service-Sistem Produk- Desain. Dalam Prosiding CIRP,
IPS2 Conference 2016, pp 537-542, CIRP, 2016.
Lampiran:.
Tabel 1: Kernel Alpha untuk Value Stream di Service Lifecycle
Kernel Alpha
Negara / Checklist 1 Negara / Checklist 2 Negara / Checklist 3 Negara / Checklist 4
strategi portfolio (S2P)
strategi: - Tentukan tujuan - Menyelaraskan bisnis dan TI
peta jalan - Mengatur standar dan kebijakan
layanan portofolio: - arsitektur Enterprise - layanan portofolio rasionalisasi - Membuat layanan cetak biru dan
roadmap
permintaan: - Konsolidasi permintaan - Menganalisis prioritas, urgensi dan
dampak - Membuatyang ada baru atau
permintaan
Seleksitag:- Bisnis nilai, risiko, biaya,
manfaat dan sumber daya - Apa-jika analisis - Memastikan pemerintahan
nama dokumen dan bagian (dokumen yang akan dikembangkan di situs pengembangan)
nama dokumen dan bagian (dokumen menjadi dikembangkan di situs pengembangan)
nama dokumen dan bagian (dokumen yang akan dikembangkan di situs pengembangan)
nama dokumen dan bagian (dokumen yang akan dikembangkan di situs pengembangan) requi nts reme untuk Deploy (R2D)
Rencana dan desain: - IT rencana proyek - model layanan Logical - Persyaratan - Fungsional dan teknis - Standar dan kebijakan
Mengembangkan: - Pengembangan tangkas, berulang,
air terjun - Sumber dan mengaturpengembangan
lingkungan- Versi kontrol - Pengembang pengujian
Test: - Fungsional: desktop web,
mobile - Kinerja: desktop web,
mobile - keamanan: statis, dinamis
Deploy: - rencana Rilis - Perubahan dankonfigurasi
proses- Pengetahuan manajemen - Aplikasi dankeamanan
dokumen monitornama dan bagian
(dokumen ke dikembangkan di situs pengembangan)
nama dokumen dan bagian (dokumen yang akan dikembangkan di situs pengembangan)
nama dokumen dan bagian (dokumen yang akan dikembangkan di situs pengembangan)
nama dokumen dan bagian (dokumen yang akan dikembangkan di situs pengembangan) Permintaan untuk Penuhi (R2F )
Desain dan Publikasikan: - item katalog Mash dari semua
mesin pemenuhan - Mengatur harga, opsi, dan SLA - Publish layanan
Langgan: - keterlibatan Portal - Persona lized pengalaman - Self-service - Mengelola langganan
Memenuhi: - Route fulfilments - otomatis penyebaran - Gunakaninternal dan eksternal
penyedia- Mengintegrasikan perubahan, aset dan
sistem konfigurasi
Ukur: - Jasa pengukuran penggunaan - Tagihan / menunjukkan kembali - transparansi Biaya - Survei dan Peringkat
nama dokumen dan bagian (dokumen yang akan dikembangkan di situs pengembangan)
nama dokumen dan bagian (dokumen yang akan dikembangkan di situs pengembangan)
nama dokumen dan bagian (dokumen yang akan dikembangkan di situs pengembangan)
nama dokumen dan bagian (dokumen yang akan dikembangkan di pembangunan situs) Mendeteksi ke Koreksi (D2C)
Mendeteksi: - Lihat peristiwa, alarm, dan metrik di seluruh infrastruktur - Memahami masalah user - Trace hubungan antara
peristiwa
Diagnosa: - Pengayaan - Akar penyebab - Severity dan bisnis dampak - Tentukan jalur eskalasi - Auto masalah umum -Tetap
Ubah: - Tentukan permintaan perubahan - Melakukan masalah danresiko
analisis- Menyetujui
Resolve: - Melaksanakan perubahan - Buku Leverage run - Verifikasi pemulihan - Tutup catatan
nama dokumen dan bagian (dokumen yang akan dikembangkan di situs pengembangan)
nama dokumen dan bagian (dokumen yang akan dikembangkan di situs pengembangan)
nama dokumen dan bagian (dokumen yang akan dikembangkan di situs pengembangan)
nama dokumen dan bagian (dokumen yang akan dikembangkan di situs pengembangan)