Interaksi internal dengan pelanggan selama desain. Pelanggan dan Kontraktor - hubungan sebagai dasar keberhasilan proyek

Tahapan umum interaksi dengan pelanggan adalah sebagai berikut:

- Komunikasi awal dengan pelanggan: mengidentifikasi tujuan dan sasaran proyek, mengidentifikasi persyaratan utama untuk sistem masa depan, pengenalan awal dengan perusahaan Pelanggan, penilaian awal waktu dan biaya proyek, persiapan dan transfer Penawaran Komersial kepada Pelanggan.
- Survei terperinci dan pengumpulan persyaratan pelanggan: penentuan komposisi tim proyek, pengumpulan persyaratan untuk sistem, mewawancarai pengguna utama dan spesialis teknis Pelanggan, pengembangan dan persetujuan Kerangka Acuan.
- Pengembangan dan pengujian sistem: setelah pengembangan sistem atau bagian tertentu dari fungsinya, demonstrasi kepada Pelanggan dilakukan. Ini diikuti dengan tahap deteksi dan penghapusan kesalahan, jika tidak ada, tes penerimaan.
- Operasi percobaan sistem: penerapan sistem di sisi Pelanggan, pelatihan pengguna, pengumpulan komentar dan saran untuk meningkatkan sistem, penghapusan komentar.
- Operasi industri sistem: operasi independen oleh Pelanggan, menghubungi layanan dukungan Perusahaan (jika perlu), mengumpulkan keinginan untuk pengembangan sistem.

Bentuk penting dari interaksi dengan pelanggan adalah dokumentasi yang dikembangkan selama pelaksanaan proyek sesuai dengan persyaratan GOST 34 dan RUP.

Kelompok kerja dibentuk untuk tugas-tugas proyek tertentu. Sinkronisasi tindakan dilakukan melalui dewan delegasi dari kelompok kerja. Anggota kelompok kerja secara mandiri mengembangkan prinsip-prinsip interaksi dalam kelompok. Kelompok dapat melibatkan anggota kelompok lain dalam memecahkan masalah. Bentuk interaksi yang berhasil baik dalam kelompok maupun antar kelompok dapat diadopsi oleh peserta proyek baru

Dunia telah lama mengakui bahwa manajemen proyek adalah bidang manajemen khusus, yang penerapannya memberikan hasil yang nyata. Profesional di bidang ini sangat dihargai (di AS ini adalah profesi dengan bayaran tertinggi ketiga setelah pengacara dan dokter), dan metodologi manajemen proyek itu sendiri telah menjadi standar manajemen de facto di ribuan perusahaan dan digunakan untuk berbagai tingkat dalam hampir semua perusahaan besar. Tahun lalu, standar manajemen proyek ANSI diadopsi, dan draf standar manajemen proyek ISO 10006 dikembangkan.

Saat ini, proses pembuatan aplikasi perangkat lunak yang kompleks tidak dapat dibayangkan tanpa membaginya ke dalam tahapan siklus hidup. Di bawah siklus hidup program, yang kami maksud adalah serangkaian tahapan:

Analisis area subjek dan pembuatan spesifikasi teknis (interaksi dengan pelanggan)
Desain struktur program
Coding (satu set kode program sesuai dengan dokumentasi proyek)
Pengujian dan Debugging
Implementasi program
Dukungan program
Pembuangan

Mari kita lihat lebih dekat proses desain. Selama proses desain, seorang arsitek atau programmer berpengalaman membuat dokumentasi proyek, termasuk deskripsi tekstual, diagram, dan model program masa depan. Dalam hal yang sulit ini, bahasa UML akan membantu kita.

UML adalah bahasa grafis untuk visualisasi, deskripsi parameter, desain dan dokumentasi berbagai sistem (khususnya program). Diagram dibuat menggunakan alat CASE khusus seperti Rational Rose (http://www-01.ibm.com/software/rational/) dan Enterprise Architect (http://www.sparxsystems.com.au/). Sebuah model informasi tunggal dibangun atas dasar teknologi UML. Alat CASE di atas mampu menghasilkan kode dalam berbagai bahasa berorientasi objek, dan juga memiliki fitur rekayasa balik yang sangat berguna. (Rekayasa terbalik memungkinkan Anda membuat model grafis dari kode program yang ada dan mengomentarinya.)

Pertimbangkan jenis diagram untuk memvisualisasikan model (ini harus dimiliki, meskipun ada lebih banyak jenis):

Gunakan diagram kasus

Sistem yang dirancang direpresentasikan sebagai seperangkat entitas atau aktor yang berinteraksi dengan sistem menggunakan apa yang disebut preseden. Dalam hal ini, aktor (aktor) atau aktor adalah setiap entitas yang berinteraksi dengan sistem dari luar. Dengan kata lain, setiap use case mendefinisikan serangkaian tindakan tertentu yang dilakukan sistem saat berbicara dengan aktor. Pada saat yang sama, tidak ada yang dikatakan tentang bagaimana interaksi aktor dengan sistem akan diimplementasikan.

Diagram kelas (diagram kelas)

Diagram kelas berfungsi untuk mewakili struktur statis model sistem dalam terminologi kelas pemrograman berorientasi objek. Diagram kelas dapat mencerminkan, khususnya, berbagai hubungan antara entitas individu dari area subjek, seperti objek dan subsistem, dan juga menggambarkan struktur internal mereka (bidang, metode ...) dan jenis hubungan (warisan, implementasi antarmuka . ..). Diagram ini tidak memberikan informasi tentang aspek waktu dari operasi sistem. Dari sudut pandang ini, diagram kelas merupakan pengembangan lebih lanjut dari model konseptual dari sistem yang dirancang. Pada tahap ini, pengetahuan tentang pendekatan OOP dan pola desain sangat penting.

Diagram keadaan (statechart diagram)

Tujuan utama diagram ini adalah untuk menggambarkan kemungkinan urutan keadaan dan transisi yang bersama-sama mencirikan perilaku elemen model selama siklus hidupnya. Diagram keadaan mewakili perilaku dinamis entitas, berdasarkan spesifikasi respons mereka terhadap persepsi beberapa peristiwa tertentu.

diagram urutan

Diagram interaksi yang tepat digunakan untuk memodelkan interaksi objek dalam bahasa UML. Interaksi objek dapat dipertimbangkan dalam waktu, dan kemudian diagram urutan digunakan untuk mewakili waktu pengiriman dan penerimaan pesan antar objek. Objek yang berinteraksi saling bertukar informasi satu sama lain. Dalam hal ini, informasi berupa pesan yang lengkap. Dengan kata lain, meskipun pesan memiliki kandungan informasi, pesan tersebut memperoleh sifat tambahan untuk memberikan pengaruh langsung pada penerimanya.

Diagram kolaborasi

Dalam diagram kerja sama, objek yang berpartisipasi dalam interaksi digambarkan dalam bentuk persegi panjang, berisi nama objek, kelasnya, dan, mungkin, nilai atribut. Seperti pada diagram kelas, asosiasi antar objek ditunjukkan dalam bentuk berbagai garis penghubung. Dalam hal ini, Anda dapat secara eksplisit menentukan nama asosiasi dan peran yang dimainkan objek dalam asosiasi ini.
Tidak seperti diagram urutan, diagram kolaborasi hanya menggambarkan hubungan antara objek yang memainkan peran tertentu dalam suatu interaksi.

Diagram Komponen

Diagram komponen, tidak seperti diagram yang dibahas sebelumnya, menggambarkan fitur representasi fisik sistem. Diagram komponen memungkinkan Anda untuk menentukan arsitektur sistem yang sedang dikembangkan dengan menetapkan dependensi antara komponen perangkat lunak, yang dapat berupa kode sumber, biner, dan yang dapat dieksekusi. Di banyak lingkungan pengembangan, modul atau komponen sesuai dengan file. Panah putus-putus yang menghubungkan modul menunjukkan hubungan ketergantungan yang serupa dengan yang terjadi saat mengkompilasi kode sumber program. Elemen grafis utama dari diagram komponen adalah komponen, antarmuka, dan ketergantungan di antara mereka.

Diagram penerapan

Diagram penyebaran dirancang untuk memvisualisasikan elemen dan komponen program yang hanya ada pada tahap eksekusinya (runtime). Dalam hal ini, hanya komponen instance program yang merupakan file yang dapat dieksekusi atau pustaka dinamis yang disajikan. Komponen-komponen yang tidak digunakan saat runtime tidak ditampilkan dalam diagram penerapan.
Diagram penyebaran berisi representasi grafis dari prosesor, perangkat, proses, dan hubungan di antara mereka. Tidak seperti diagram representasi logis, diagram penyebaran sama untuk sistem secara keseluruhan, karena harus sepenuhnya mencerminkan fitur implementasinya. Diagram ini pada dasarnya melengkapi proses OOAP untuk sistem perangkat lunak tertentu, dan pengembangannya biasanya merupakan langkah terakhir dalam spesifikasi model.

Ini menyimpulkan gambaran kami tentang diagram pada khususnya dan desain pada umumnya. Perlu dicatat bahwa proses desain telah lama menjadi standar pengembangan perangkat lunak, tetapi seringkali Anda harus berurusan dengan program yang ditulis dengan indah, yang, karena kurangnya dokumentasi yang tepat, memperoleh fungsionalitas samping yang tidak perlu, kruk, menjadi tidak praktis dan kehilangan fungsinya. kualitas mantan. =(

Saya yakin bahwa seorang programmer pada dasarnya adalah seorang pembuat kode - dia TIDAK boleh berkomunikasi dengan pelanggan, TIDAK boleh memikirkan arsitektur sistem, tidak boleh menciptakan antarmuka ke program, dia hanya boleh membuat kode - mengimplementasikan algoritma, fungsionalitas, penampilan, kegunaan, tapi tidak lebih .... Perancang, mulai dari diagram abstrak (menggambarkan area subjek) hingga diagram yang mewakili struktur data, kelas, dan proses interaksinya, harus menggambarkan semuanya langkah demi langkah secara detail. Artinya, kompleksitas pekerjaan dan gaji seorang desainer harus lebih tinggi daripada seorang programmer == coder. Maaf untuk curhatnya....

1.1. Interaksi dengan Pelanggan (Fungsi Utama)

1.1.1. Pencarian pesanan

7.2.3.1. Untuk informasi produk

1.1.2. Pekerjaan pra-kontrak dengan Pelanggan

Dokumen peraturan

2.2.1.2.1. Pekerjaan pra-kontrak dengan Pelanggan STP-1-01

Persyaratan Sistem Manajemen Mutu ISO9000:2000 Klausul 7

7.2.1.1. Persyaratan pelanggan untuk produk, termasuk persyaratan untuk ketersediaan, pengiriman, dan pemeliharaan

7.2.2.4. Penentuan kemampuan untuk mencapai kepatuhan dengan persyaratan tertentu

// Analisis kebutuhan produk / Proses yang berhubungan dengan konsumen / PENJUALAN PRODUK

1.1.3. Pembentukan Kerangka Acuan

Dokumen peraturan

2.2.1.2.2. Prosedur untuk analisis dan kesimpulan kontrak STP-2-01 // Standar Enterprise Enterprise Ellat (STP) / Dokumen sistem manajemen mutu / Dokumen peraturan internal / Peraturan

Persyaratan Sistem Manajemen Mutu ISO9000:2000 Klausul 7

7.2.1.2. Persyaratan tidak ditentukan oleh pelanggan, tetapi diperlukan untuk penggunaan yang dimaksudkan atau ditentukan // Definisi kebutuhan pelanggan / Proses terkait pelanggan / PENJUALAN PRODUK

7.2.1.3. Kewajiban terkait produk, termasuk persyaratan wajib dan ketentuan hukum // Definisi kebutuhan pelanggan / Proses terkait pelanggan / PENJUALAN PRODUK

// Analisis kebutuhan produk / Proses yang berhubungan dengan konsumen / PENJUALAN PRODUK

7.2.2.2. Konfirmasi persyaratan konsumen sebelum penerimaannya, jika konsumen tidak memberikan pernyataan persyaratan tertulis // Analisis kebutuhan produk / Proses yang berhubungan dengan konsumen / PENJUALAN PRODUK

7.2.2.3. Klarifikasi perubahan persyaratan kontrak atau pesanan yang berbeda dari yang diajukan sebelumnya (misalnya, dengan penawaran atau tautan) // Analisis kebutuhan produk / Proses yang berhubungan dengan konsumen / PENJUALAN PRODUK

7.3.1.1. Penentuan tahapan proses desain dan/atau pengembangan

7.3.2.2. Persyaratan hukum dan peraturan yang berlaku

7.3.2.3. Data yang berlaku berasal dari perkembangan sebelumnya yang serupa // Input data untuk desain dan pengembangan / Desain dan pengembangan / PENJUALAN PRODUK

7.3.2.4. Persyaratan lain yang penting untuk desain dan pengembangan // Input data untuk desain dan pengembangan / Desain dan pengembangan / PENJUALAN PRODUK

7.3.4.1. Menilai kemampuan untuk memenuhi persyaratan

1.1.4. Kesimpulan Perjanjian

Dokumen peraturan

2.2.1.2.3. Peraturan tentang pekerjaan kontrak dengan Pelanggan (STP-3-01) // Standar Perusahaan Ellat (STP) / Dokumen sistem manajemen mutu / Dokumen peraturan internal / Peraturan

1.1.5. Memantau pemenuhan kewajiban kontraktual

Dokumen peraturan

2.2.1.2.3.2. Prosedur untuk menganalisis perubahan dan membuat perubahan pada Dokumen Kontrak // Peraturan tentang pekerjaan kontrak dengan Pelanggan (STP-3-01) / Standar Perusahaan Ellat (STP) / Dokumen sistem manajemen mutu / Dokumen peraturan internal / Peraturan

2.2.1.2.4.1. Prosedur penanganan keluhan dan klaim Nasabah

2.2.1.2.4.2. Prosedur untuk menghilangkan komentar Pelanggan // Regulasi tentang tindakan korektif dan pencegahan (STP-4-01) / Ellat Enterprise Standards (STP) / Dokumen sistem manajemen mutu / Dokumen regulasi internal / Regulasi

Persyaratan Sistem Manajemen Mutu ISO9000:2000 Klausul 7

7.2.3.2. Memproses permintaan, kontrak, pesanan, termasuk perubahan // Komunikasi dengan konsumen / Proses yang berhubungan dengan konsumen / PENJUALAN PRODUK

1.2. Penjadwalan Pekerjaan Proyek (Fungsi Utama)

1.2.1. Klarifikasi komposisi kompleks dan ruang lingkup pengembangan

Dokumen peraturan

// Standar Perusahaan Ellat (STP) / Dokumen sistem manajemen mutu / Dokumen peraturan internal / Peraturan

Persyaratan Sistem Manajemen Mutu ISO9000:2000 Klausul 7

7.2.2.1. Definisi persyaratan produk // Analisis kebutuhan produk / Proses yang berhubungan dengan konsumen / PENJUALAN PRODUK

1.2.2. Perencanaan Jaminan Kualitas Proyek

Dokumen peraturan

2.2.1.2.5. Komposisi dan prosedur untuk mengembangkan program jaminan kualitas proyek (STP-5-01) // Standar Perusahaan Ellat (STP) / Dokumen sistem manajemen mutu / Dokumen peraturan internal / Peraturan

Persyaratan Sistem Manajemen Mutu ISO9000:2000 Klausul 7

7.1.1. Menetapkan sasaran kualitas untuk suatu produk, proyek, atau kontrak

7.1.3. Definisi kegiatan peninjauan dan persetujuan serta kriteria penerimaan // Perencanaan proses penjualan / PENJUALAN PRODUK

7.2.2.5. Memperbaiki hasil analisis dan tindak lanjut selanjutnya (lihat klausul 5.5.7) // Analisis kebutuhan produk / Proses yang berhubungan dengan konsumen / PENJUALAN PRODUK

7.3.1.2. Definisi kegiatan peninjauan, verifikasi, dan persetujuan untuk setiap tahap desain dan/atau pengembangan // Desain dan perencanaan pengembangan / Desain dan pengembangan / PENJUALAN PRODUK

1.2.3. Pembentukan spesifikasi teknis swasta untuk pengembangan komponen kompleks

Dokumen peraturan

2.2.1.2.7. Teknologi implementasi proyek. Tahapan dan urutan pekerjaan (STP-7-01) // Standar Perusahaan Ellat (STP) / Dokumen sistem manajemen mutu / Dokumen peraturan internal / Peraturan

1.2.4. Perencanaan proyek

Dokumen peraturan

// Standar Perusahaan Ellat (STP) / Dokumen sistem manajemen mutu / Dokumen peraturan internal / Peraturan

Persyaratan Sistem Manajemen Mutu ISO9000:2000 Klausul 7

7.1.2. Penentuan kebutuhan untuk menetapkan proses dan dokumentasi, menyediakan sumber daya dan infrastruktur khusus untuk produk // Perencanaan proses penjualan / PENJUALAN PRODUK

1.2.5. Koordinasi dan pengendalian operasional kinerja kerja

Dokumen peraturan

2.2.1.2.4.3. Prosedur Tindakan Korektif // Peraturan tentang tindakan korektif dan pencegahan (STP-4-01) / Standar Perusahaan Ellat (STP) / Dokumen sistem manajemen mutu / Dokumen peraturan internal / Peraturan

2.2.1.2.6. Peraturan tentang perencanaan kerja (STP-6-01) // Standar Perusahaan Ellat (STP) / Dokumen sistem manajemen mutu / Dokumen peraturan internal / Peraturan

Persyaratan Sistem Manajemen Mutu ISO9000:2000 Klausul 7

7.3.4.2. Identifikasi masalah dan penyusunan proposal untuk tindak lanjut // Analisis Desain dan Pengembangan / Desain dan Pengembangan / PENGIRIMAN PRODUK

7.3.7. Manajemen perubahan desain dan pengembangan

1.3. Pengembangan desain, perangkat lunak dan dokumentasi operasional (Fungsi utama)

1.3.1. Pengembangan dokumentasi untuk perangkat keras kompleks

Dokumen peraturan

2.2.1.2.7. Teknologi implementasi proyek. Tahapan dan urutan pekerjaan (STP-7-01) // Standar Perusahaan Ellat (STP) / Dokumen sistem manajemen mutu / Dokumen peraturan internal / Peraturan

2.3.3.3. Rencana kerja untuk pengembangan perangkat keras dan departemen produksi

1.3.2. Pengembangan bagian perangkat lunak dari kompleks

Dokumen peraturan

2.2.1.2.7. Teknologi implementasi proyek. Tahapan dan urutan pekerjaan (STP-7-01) // Standar Perusahaan Ellat (STP) / Dokumen sistem manajemen mutu / Dokumen peraturan internal / Peraturan

2.3.3.4. Rencana kerja untuk pengembangan perangkat lunak dan departemen produksi // Program dan rencana aksi / Dokumen organisasi dan administrasi perusahaan / Peraturan

1.3.4. Analisis dan persetujuan hasil desain

Dokumen peraturan

2.2.1.2.7. Teknologi implementasi proyek. Tahapan dan urutan pekerjaan (STP-7-01) // Standar Perusahaan Ellat (STP) / Dokumen sistem manajemen mutu / Dokumen peraturan internal / Peraturan

Persyaratan Sistem Manajemen Mutu ISO9000:2000 Klausul 7

7.3.3.1. Sesuai dengan persyaratan input desain dan pengembangan

7.3.3.2. Memberikan informasi yang sesuai untuk operasi manufaktur dan jasa (lihat 7.5) // Hasil desain dan pengembangan / Desain dan pengembangan / PRODUCT MAILING

7.3.3.4. Tentukan karakteristik produk yang penting untuk penggunaan yang aman dan tepat. // Hasil desain dan pengembangan / Desain dan pengembangan / PRODUCT MAILING

7.3.5.1. Kesesuaian data keluaran dengan persyaratan masukan // Verifikasi Desain dan Pengembangan / Desain dan Pengembangan / PENJUALAN PRODUK

7.3.6. Persetujuan hasil desain dan pengembangan // Desain dan pengembangan / PRODUK PENJUALAN

Pendidikan, Pengembangan, Pelatihan

Kata kunci:

1 -1

Pertimbangkan skema penuh interaksi dengan pelanggan pada contoh pengembangan situs web. Secara grafis, tahapan interaksi dapat direpresentasikan sebagai gambar berikut:

primer adalah panggilan atau surel, yang diproses oleh pengelola akun. Manajer berbicara tentang layanan perusahaan Sarang Lebah, memberikan jawaban atas semua pertanyaan yang menarik dan menjelaskan proses interaksi lebih lanjut kepada pelanggan.

* Perlu dicatat bahwa pelanggan dialokasikan manajer pribadi untuk seluruh periode proyeknya, yang siap menjawab semua pertanyaan dan membantu menyelesaikan semua masalah.

Selanjutnya, manajer membantu menyelesaikan bentuk singkat untuk pengembangan situs web yang berisi pertanyaan klarifikasi yang diperlukan tentang masalah kerjasama dan menambahkan kontak ke sistem CRM internal (Sistem Manajemen Hubungan Pelanggan).

Data dimasukkan ke dalam sistem untuk menyimpan semua data pelanggan yang diperlukan dengan aman dan untuk memastikan pengembangan kualitas situs secara keseluruhan.

Berdasarkan brief yang telah selesai, spesialis Sarang Lebah mempersiapkan penawaran komersial individu dengan deskripsi waktu dan biaya pekerjaan dan manajer mengirimkannya ke pelanggan untuk dipertimbangkan.

Selanjutnya adalah proses menyepakati syarat-syarat kerjasama, yang hasilnya adalah perjanjian. Untuk mempercepat dimulainya pekerjaan, kontrak ditandatangani oleh kedua belah pihak dan para pihak bertukar salinan pindaian kontrak. Dokumen asli kontrak dikirim melalui pos tercatat (selanjutnya, semua salinan kertas ditukarkan melalui pos atau kurir). Setelah pihak menerima aslinya dalam bentuk kertas, satu salinan dikirim kembali melalui pos.

*Proses dari pemanggilan hingga penandatanganan kontrak biasanya memakan waktu tidak lebih dari 1-2 hari.

Setelah menandatangani kontrak dan menukar salinan pindaian elektronik, pelanggan membayar uang muka, yang biasanya berjumlah 50% dari total jumlah kontrak.

Setelah menerima uang muka dan melakukan analisis area subjek, tahap pengembangan dan persetujuan dimulai kerangka acuan (TOR), di mana semua persyaratan untuk situs yang sedang dikembangkan ditentukan, skema diberikan dan prototipe terperinci dari seluruh situs dibuat. TK adalah lampiran wajib kontrak, disetujui oleh kedua belah pihak dan ditandatangani dengan cara yang sama seperti kontrak.

* Harus dipahami bahwa kerangka acuan adalah dokumen yang sangat penting bagi kontraktor dan pelanggan. Hal ini memungkinkan Anda untuk merancang dan melaksanakan proyek Internet dengan kualitas tinggi dan tepat waktu.

Setelah semua persyaratan disetujui, pelanggan dikirim daftar teks dan bahan grafis yang diperlukan, yang harus disediakan oleh pelanggan sebelum dimulainya tahap pengembangan (yaitu selama pengembangan tata letak desain oleh kontraktor, pelanggan mengumpulkan dan menyediakan semua bahan yang diperlukan). Daftar ini dapat mencakup: deskripsi perusahaan, dengan siapa mereka bekerja sama, penghargaan dan sertifikat apa yang mereka miliki, daftar harga dan harga, katalog produk dan deskripsi barang, deskripsi layanan, informasi kontak yang dipublikasikan di situs, dll.

Terkadang sulit bagi pelanggan untuk menggambarkan layanannya sendiri atau tidak ada waktu untuk itu. Dalam hal ini, kontraktor siap untuk menyelesaikan pekerjaan menulis konten yang hilang untuk situs (gambar, teks, video, dll.).

* Menyediakan pelanggan dengan bahan yang diperlukan sangat penting karena:

perlu untuk memasukkan semua konten yang disediakan oleh pelanggan dengan benar ke dalam tata letak situs sekaligus (tidak masuk akal untuk melakukan pekerjaan ekstra);
proses teknologi pemain dijadwalkan secara harfiah "per menit" dan kami tidak ingin melanggarnya dan menimbulkan biaya tambahan;
mengisi proyek Internet dengan informasi pengujian juga tidak masuk akal (pertama, jumlah pekerjaan yang tidak perlu meningkat lagi; kedua, mesin pencari dapat meremehkan situs yang dihosting dengan konten pengujian; ketiga, pelanggan potensial Anda mungkin memiliki sikap negatif terhadap situs, yang berisi informasi yang jelas tidak berguna);
Penting bagi Anda dan kami untuk menyelesaikan proyek secara profesional dan tepat waktu.

* Pelanggan yang terhormat, tolong jangan tunda pengembangan situs Anda sendiri dan dapatkan untung darinya. Menyediakan konten tepat waktu! Jika tidak, proyek akan dibekukan sampai kami menerima informasi dari Anda dan, karenanya, batas waktu pengiriman situs telah ditunda. Jika tidak ada waktu untuk mengumpulkan dan menulis informasi, memesan teks tulisan dan pemrosesan foto kepada kami, itu murah.

Secara paralel, kelompok kerja untuk proyek dibuat dan panggung dimulai pengembangan tata letak desain situs masa depan.
Setelah tata letak desain siap, itu dikirim ke pelanggan untuk persetujuan. Setelah disetujui, mockup menjadi desain yang valid.

* Tergantung pada kompleksitas proyek, pelanggan dapat diberikan akses ke sistem manajemen proyek (misalnya, Redmine), di mana Anda dapat mengunggah sumber daya proyek yang diperlukan, memantau tahap pengembangan, dan menerbitkan komentar.

Untuk kelanjutan pekerjaan lebih lanjut, wajib menerima dari pelanggan semua bahan yang diperlukan, yang daftarnya telah dikirim ke pelanggan sebelumnya.

Segera setelah bahan yang hilang diterima. Penting tahap pengembangan situs sesuai dengan TOR yang disetujui.
Tahap ini mencakup sejumlah besar jenis pekerjaan: ini adalah tata letak lintas-browser tata letak situs, pengembangan template desain yang diperlukan untuk sistem manajemen konten (CMS) yang dipilih, pemasangan dan konfigurasi CMS itu sendiri, pemasangan yang diperlukan modul dan komponen, pengembangan modul yang hilang, studi komprehensif tentang algoritme operasi situs web , mengisi situs dengan konten, menerapkan proyek pada domain teknis, dan melanjutkan ke pengujian.

Pengujian proyek Internet dilakukan oleh spesialis kontraktor, semua kesalahan dan komentar dihilangkan, situs disesuaikan untuk pekerjaan.

Segera setelah pekerjaan selesai dan pengujian situs pada domain teknis selesai, tahap serah terima. Di sini, di pihak pelanggan, pemenuhan persyaratan TOR dan seluruh proses berfungsinya proyek Internet diperiksa.
Setelah pelanggan membuat keputusan tentang kepatuhan penuh situs dengan persyaratan TOR, situs ditransfer ke pelanggan dan proyek dipublikasikan di hosting.

Hasil dan konfirmasi penyerahan dan penerimaan pekerjaan adalah tempat yang dapat dikerjakan dan tindakan penerimaan, yang ditandatangani oleh kedua belah pihak. Tindakan yang ditandatangani, bersama dengan seluruh rangkaian dokumen untuk akuntansi, dikirim melalui pos.

Setelah menandatangani sertifikat penerimaan, pelanggan, sesuai dengan kontrak, membayar sisa biaya pekerjaan.

Setelah perhitungan akhir, bersama dengan dokumen dan situs web, pelanggan menerima panduan pengguna, salinan situs di DVD dan gratis dukungan teknis dalam waktu 2-4 minggu sejak tanggal penerimaan situs.

Dalam diagram ini, kami mencoba untuk sepenuhnya mencerminkan semua aspek interaksi dari panggilan awal hingga pengiriman proyek. Untuk proyek sederhana, beberapa langkah dapat digabungkan atau dihilangkan. Tetapi bagaimanapun juga, semuanya tercermin dalam kontrak.

Skema kerja untuk layanan "Pengembangan situs web komprehensif", serta "Promosi situs web" secara struktural mengulangi proses interaksi antara pelanggan dan kontraktor yang dijelaskan di atas dan oleh karena itu tidak memerlukan deskripsi terperinci.

Kami berharap skema interaksi yang dijelaskan transparan dan dapat dimengerti. Jika Anda masih memiliki pertanyaan, silakan

Proyek:	Distribusi kueri ke katalog elektronik berdasarkan indeks pencarian dan istilah pencarian
Ruang lingkup proyek:	13.02.2006 - 05.06.2006
Pelanggan:	Perpustakaan Ilmiah Universitas Negeri Petrozavodsk.
Bertanggung jawab:	Gorshkova Galina Anatolyevna, kepala departemen pemrosesan dokumen komputer dan pembuatan katalog. Surel surat: . Budak. tel.: 719602. Perpustakaan: taksi. 102. Guryev Dmitry Borisovich, programmer terkemuka RCNIT. Surel surat: . Budak. tel.: 784775. Pusat Internet.
Pengajar:	Kulakov Kirill Alexandrovich Surel: . Telepon kantor: 711015. Kamar 215
Informasi untuk instruktur:	Grup nomor 13
Dokumen yang berkaitan:	Tinjauan Proyek Rencana Proyek Jadwal Kerja (Gantt Chart) Persyaratan Spesifikasi Desain Uji Pelaksanaan Dokumen Dokumen Uji Customer Engagement Laporan Hubungan Pengembang Kemajuan Pengembangan Glosarium Panduan Pengguna

Pertemuan pertama dengan klien.

Pada pertemuan pertama, tim pengembang diperkenalkan kepada pelanggan. Pelanggan, pada gilirannya, berbicara tentang perpustakaan ilmiah PetrSU.

Perpustakaan beroperasi berdasarkan sistem otomatis "Foliant". Katalog elektronik merupakan bagian dari sistem perpustakaan. Pencarian katalog dilakukan dengan menggunakan query. Operator menghasilkan string pencarian yang mungkin berisi sejumlah besar indeks pencarian dan istilah pencarian. Setiap permintaan dicatat dalam tabel log. Tabel ini berisi data waktu permintaan, alamat klien yang membuat permintaan, permintaan itu sendiri, hasil permintaan.

Pelanggan perlu terus memantau tabel log dan memberikan beberapa statistik tentang penggunaan indeks pencarian.

Persyaratan awal untuk proyek yang sedang dilaksanakan juga disajikan. Salah satu syaratnya adalah kompilasi statistik yang efisien. Artinya, statistik harus ditampilkan setelah waktu yang wajar setelah mengirim permintaan. Karena persyaratan ini, pengembang didorong untuk menggunakan prosedur sisi server di PL/SQL.

Pertemuan kedua dengan klien.

Pelanggan memberi pengembang login dan kata sandi untuk memasuki sistem katalog elektronik, menyediakan salinan dua tabel untuk bekerja - tabel log dan tabel indeks pencarian.

Guryev Dmitry Borisovich memperkenalkan kami secara lebih rinci dengan pekerjaan di klien Oracle SQL*Plus DBMS. Tim berkenalan dengan pekerjaan katalog elektronik.

Sistem "Foliant" bekerja berdasarkan standar RusMark, yang berisi sekitar 99 bidang. Setiap perpustakaan yang bekerja dengan AIBS "Foliant" memilih bidang dan subbidang yang akan digunakan. Ada GOST khusus yang menjelaskan aturan untuk menyimpan data perpustakaan. Karena ada banyak bidang, kami membuat sistem indeks pencarian. Ada indeks layanan dan publik.

Pengguna direktori dibagi menjadi internal dan eksternal. Setiap departemen atau karyawan diberikan haknya sendiri. Setiap record tentang suatu objek diurai menjadi elemen-elemen terpisah dan tidak disimpan secara keseluruhan.

Pertemuan ketiga dengan pelanggan.

Pelanggan telah memberi kami persyaratan yang jelas secara tertulis.

Pelanggan tertarik dengan statistik berikut:

Jumlah permintaan ke katalog elektronik.

Selama sebulan terakhir dari hari ke hari.
Akuntansi bulanan untuk tahun berjalan.
Akuntansi menurut tahun.
Buat sejarah informasi.

Daftar permintaan oleh untuk masing-masing indeks pencarian di mana hasil pencariannya nol.

Daftar permintaan yang sering terjadi.

Analisis eksekusi permintaan untuk periode tertentu. Laporan harus mencakup statistik berikut:

Jumlah permintaan.
Jumlah permintaan pencarian.
Jumlah kueri yang kompleks.
Jumlah respons yang berhasil.
Jumlah tanggapan nol.
Pengarang
Penulis rev. melecut.
Jenis dokumen.
Bagian geografis.
Masukkan tanggal.
Tanggal penerbitan.
Judul.

Pertemuan keempat dengan klien.

Spesialis dari pelanggan Guryev D.B. menjelaskan seluk-beluk menginstal dan mengkonfigurasi utilitas SQL*Plus. Solusi untuk masalah peluncuran program adalah menginstal paket SQL * Net, juga Guryev D.B. memberikan nama tabel yang tepat untuk pengembang, dan juga menambahkan tabel lain yang tersedia untuk tim. Spesialis mempelajari dokumen arsitektur dan mengusulkan untuk secara praktis mengimplementasikan semua jenis arsitektur dan memilih yang paling optimal. Pada saat yang sama, diinginkan untuk tidak membangun kembali tabel-log dan, sebanyak mungkin, memecahkan masalah tertentu, menggeneralisasi data dari tabel-log untuk digunakan lebih lanjut dalam berbagai statistik lokal.

Pelanggan Gorshkova G.A. berkenalan dengan dokumen persyaratan, setelah menyetujuinya.

Pertemuan kelima dengan pelanggan.

Guryev Dmitry Borisovich, seorang spesialis dari sisi pelanggan, diundang untuk menginstal perangkat lunak yang diperlukan untuk bekerja dengan DBMS "Oracle" di server pelatihan PetrSU. Vadim Anatolyevich Ponomarev, yang memiliki akses administratif ke server PetrSU, juga terlibat dalam proses ini dari pihak universitas.