Roaming call flow: MSRN (Mobile Station Roaming Number)

MSRN (Mobile Station Roaming Number) adalah nomor sementara yang digunakan pada jaringan GSM untuk keperluan routing saat ada pemanggilan (terminated call) ke MS (mobile station).

MSRN dialokasikan pada seorang subscriber saat subscriber berada di visited network atau sedang roaming di jaringan operator lain. MSRN yang dialokasikan hanya bersifat sementara pada VLR/MSC. Setiap MSC biasanya memiliki range dimana MSRN bisa dialokasikan.

Pengalokasian MSRN hanya dilakukan sesaat ketika MT call akan berlangsung sampai percakapan benar-benar terjadi.

• Ketika GMSC menerima ISUP IAM message, GMSC akan meminta informasi routing ke HLR.
• Kemudian HLR akan meminta informasi nomor roaming (MSRN) ke serving VLR/MSC.
• Informasi MSRN kemudian dikirimkan VLR lewat HLR ke GMSC.
• Berdasarkan nomor MSRN, GMSC akan mengirimkan ISUP IAM message ke serving VLR/MSC.
• Pada saat percakapan terjadi, MSRN sudah dihapus di VLR.

Gambar pada dokumen ini akan membantu pemahaman kita.

Format MSRN mengikuti penomoran E.164. Strukturnya sama dengan MSISDN yaitu

• Country Code (CC) dari visited network
• National Destination Code (NDC) dari visited network
• Subcriber Number (SN) yang dialokasikan oleh visited network

Karena MSRN pada dasarnya adalah nomor MSISDN, maka range nomor ini juga harus diplan oleh sebuah operator GSM.

PMBOK edisi 4 (terbaru)

Memang sudah agak basi posting ini. Buat yang belum tau PMBOK edisi terbaru yaitu edisi ke-4 sudah dipublikasikan bulan Januari 2009.

Perubahan-peruban penting adalah:

• Proses Develop Preliminary Scope Statement dihapus
• “Close Project” diubah menjadi “Close Project or Phase Plan Scope”
  
• Penambahan proses Collect requirements
  
• Manage Project Team dipindahkan dari controlling process ke executing process
• Manage Stakeholders diubah menjadi Manage Stakeholder Expectations
• Penambahan proses baru yaitu Identify Stakeholders pada initiating process group yang outpunya adalah stakeholder register dan stakeholder management strategy.
  
• Arrow Diagramming Method sebagai alat activity sequencing dihapus dari section 6 (Project Time Management)
  
• Penjelasan tentang earned value di chapter 7 dan ditambahkan bagian tentang kalkulasi To Complete Performance Index (TCPI) pada proses Control Cost
  
• Develop Project Team dan Manage Project Team dibahas lebih mendalam di chapter 9. Ini ditambah juga dengan appendix baru tentang Interpersonal Skills yang mencakup:
  • Leadership
  • Team building
  • Motivation
  • Communication
  • Influencing
  • Decision making
  • Political and cultural awareness
  • Negotiation
• Pada chapter 12 tentang Project Procurement Management, sebelumnya terdiri dari 6 proses dirangkum menjadi 4 proses yaitu: Plan Procurements, Conduct Procurements, Administer Procurements dan Close Procurements.
  
  Plan purchase and Acquisitions dan Plan Contracting diubah menjadi Plan Procurements.
  Request Seller Responses” dan Select Sellers diubah menjadi Conduct Procurements.
  
  
• Konsep tentang Teaming Agreements” juga diperkenalkan di chapter 12

Lebih detailnya silahkan lihat di sini

Metode identifikasi resiko proyek pengembangan software dengan TBQ

Cara atau metode identifikasi resiko (risk) dari suatu proyek bermacam-macam. Dalam posting ini saya akan membahas tentang metode TBQ yang dibuat spesifik untuk proyek software development.


SEI (Software Engineering Institure) adalah organisasi yang mengembangkan sebuah metode untuk identifikasi resiko dalam proyek pengembangan perangkat lunak (software development) yang disebut Taxonomy-Based Questionnaire.

Dalam membuat metode identifikasi resiko, SEI memulai dengan asumsi-asumsi sebagai berikut:

• Resiko dalam software development secara general telah diketahui oleh staf teknis proyek tetapi sangat minim dikomunikasikan.
• Sebuah metode yang terstruktur dan dalam diulangin (repeatable) dalam indentifikasi resiko dibutuhkan untuk managemen resiko yang konsisten.
• Indentifikasi resiko yang efektif haruslah mencakup semua bagian area pengembangan dan support dari project.
• Proses identifikasi resiko haruslah membuat dan menjaga agar terbentuk lingkungan yang tidak menghakimi (non-judgmental) dan non-attributive risk sehingga kita dapat mendengarkan pandangan-pandangan yang (tentative) dan kontroversial.
  
• Sukses tidak-nya suatu proyek tidak adapat disimpulkan semata-mata dari resiko yang tidak diketahui (uncovered).

Dalam mengembangkan metode TBQ, SEI memulai dengan mendefinisikan taxonomy atau lebih tepatnya "Software Development Risk Taxonomy". Taxonomy adalah framework untuk mengorganisasi dan mempelajari isu-isu pengembangan software. Software taxonomy terdiri dari 3 kelas utama yaitu

1. Product Engineering
   Requirement, Design, Code and Unit Test, Integration and Test, Engineering Specialities
2. Development Environment
   Development Proceds, development System, Management Process, Management Methods, Work Environment
3. Program Contraints
   Resources, Contract, Program Interface

Setiap kelas tersebut kemudian di-breakdown menjadi beberapa elemen dan tiap elemen dikarakterisasi dengan atribut-atribut. Dibawah ini ilustrasi diagram pohon dari software development taxonomy:



Detail taxonomy yang digunakan untuk TBQ adalah sebagai berikut




Dari taxonomy tersebut kemudian dibuat sebuah list pertanyaan untuk mengidentifikasi resiko dalam pembangunan software. List pertanyaan (questinnaire) dapat dilihat di Appendix B dari dokumen TBQ yang dipublikasikan oleh SEI. Dibawah ini adalah capture dari beberapa pertanyaan dalam TBQ.



Pelaksanaan TBQ dalam prakteknya dapat dijalankan dalam bentuk risk identification session yaitu sebuah sesi tanya-jawab (interview) dari orang-orang yang dipilih dalam proyek. Orang yang terlibat dalam diskusi adalah orang-orang dari shareholder proyek, yang mencakup orang yang berada dalam hirarki organisasi proyek maupun orang fungsional seperti developer, upport, dan lain-lain. Sebelum pelaksaan sesi identifikasi resiko yang akan berisi tanya-jawab dan klarifikasi issue, sebaiknya dilakukan training