e-javanensis

Topik yang paling menarik dalam Project Management

noreply@blogger.com (eJLp12) — Fri, 31 Dec 2010 11:27:00 +0000

Sudah beberapa bulan ini berhenti menulis di blog. Sungguh bulan-bulan yang menyibukkan sehingga produktifitas posting di blog menjadi berkurang. Tapi bukan berarti berhenti belajar dan menulis, beberapa hal baru dipelajari dan didokumentasikan dan bisa saya bagi disini.

Beberapa bulan yang lalu saya memutuskan untuk mempublikasikan file-file presentasi training PMP yang saya buat. Saya jamin kulitas konten pada slide yang saya buat tidak kalah dengan apa yang Anda bisa dapat dari perusahaan yang menawarkan training PMP di Indonesia. Point-point penting untuk mendapatkan sertifikasi PMP dari buku PMBOK maupun Buka Rita Mulchahi bisa didapatkan pada slide presentasi yang saya bikin.

Slide presentasi tersebut dan juga slide yang lain bisa Anda lihat di http://www.slideshare.net/ejlp12/presentations.

Saya belum berniat untuk membuat file tersebut downloadable, tapi jika Anda berminat untuk mendapatkan softcopy atau hardcopy-nya, silakan hubungi saya lewat email. Mudah-mudah berguna, dan jika ada kesalahan dalam slide tersebut silakan beritahukan saya juga.

Dari slide presentasi saya tersebut, saya melihat topik Project Risk Management adalah topik yang banyak dicari dan dilihat dari beberapa topik pada project management. Tidak heran, buat saya risk management juga memang hal yang menarik saat awal-awal mempelajari topik project management dan biasanya menjadi hal yang dilupakan buat project manager pemula seperti saya.

Berikut adalah urutan dari slide dengan topik project management yang paling banyak dilihat:

1. Project Risk Management

2. Project Human Resource Management

3. Project Communication Management

4. Project Quality Management

5. Introduction to Framework (PMBOK)

6. Project Time Management

7. Project Cost Management

8. Project Procurement Management

9. Project Scope Management

10. Project Integration Management

TMForum Frameworx = The next of NGOSS

noreply@blogger.com (eJLp12) — Mon, 07 Jun 2010 09:30:00 +0000

Bulan Maret lalu TMForum mengumumkan sebuah Service-oriented Integrated Business Architecture yang disebut Frameworx.

Frameworx merupakan kumpulan framework yang dikembangkan dari framework yang sudah ada pada NGOSS dengan suatu pendekatan baru yaitu service-oriented dan standar proses arsitektur IT seperti ITIL dan TOGAF sehingga menjadi suatu blueprint untuk mengimplementasikan Service Oriented Enterprise.

Frameworx rencananya akan dirilis secara penuh bulan Juni ini. Beberapa deliverables dari Frameworx ini adalah:

Business Process Framework (eTOM) version 8
Information Framework (SID) version 9
Application Framework (TAM) version 4
Integration Framework version 2
A platform architecture approach to facilitate collaboration and management of value chain and outsourcing partners
Frameworx Roadmap release 1, showing the release strategy and content for the next 12 months

Lebih lanjut silakan lihat tautan berikut:

- Press release

- Halaman TMForum Frameworx.

Memilih Metodologi Manajemen Proyek

noreply@blogger.com (eJLp12) — Mon, 31 May 2010 08:09:00 +0000

Sebuah perusahaan vendor IT atau vendor apapun yang hidup matinya bergantung pada keberadaan proyek, memiliki masalah yang sama dalam menentukan metodologi apa yang cocok untuk digunakan dalam pengerjaan proyek. Dalam dunia IT lebih dalam lagi akan ada pertanyaan metodologi apa yang cocok untuk pengembangan software atau untuk digunakan sebagai acuan Software Development Life Cycle (SDLC).

Pengalaman membuktikan, tidak adanya kejelasan metodologi yang jelas yang digunakan perusahaan akan membuat proyek berjalan tanpa arah dan akan sangat tergantung dari individu manajer proyeknya. Jika kondisi itu berlangsung pada proyek yang kompleks dan ditangani oleh manajer proyek yang tidak berpengalaman maka akan berakhir pada kegagalan proyek. Bagi orang yang lebih tinggi yaitu atasan dari manajer proyek, hal tersebut akan membuat proyek-proyek tidak bisa dimonitor apalagi dikontrol.

Memilih metodologi proyek memang bukan hal yang mudah. Kita tau ada berbagai macam metodologi mulai yang general, yang bisa diimplementasikan pada proyek apapun seperti PMBOK, PRINCE2 maupun yang spesifik untuk domain tertentu misalnya SWEBOK, XP, Scrum yang digunakan pada proyek development software. Masing-masing metodologi memiliki keuntungan dan kita perlu untuk TIDAK memilih begitu saja satu metodologi karena saya percaya tidak ada metodologi yang "one size fits all."

Kita dapat mengelaborasikan beberapa metodologi dan membuatnya pesifik untuk perusahaan dengan catatan metodologi tersebut didefinisikan agar sesuai dengan sifat dari proyek-proyek yang ada dan sebisa mungkin masih dapat disesuaikan (tailored) sesuai dengan besarnya proyek.

Untuk mengelaborasi metodologi, sebaiknya kita mulai dengan studi beberapa metodologi yang sudah ada. Ada baiknya kita membuat listing yang lengkap dari metodologi yang yang sudah ada, mempelajarinya secara high level, kemudian menentukan yang menjadi main interest, lalu melakukan klasifikasi seperti yang dijelaskan sebuah artikel "Defining & Classifying Project Management Methodologies." Berikut ini gambaran level dari klasifikasi metodologi manajemen proyek dari artikel tersebut.

Ada baiknya perusahaan membuat sebuah referensi metodologi manajemen proyek pada Level 3 (Organization specific, customized methodology). Yang dibuat sedemikian rupa sehingga dapat diadaptasi menjadi L4 maupun L5 sesuai kemampuan manajer proyek.

Sebuah kesimpulan yang menarik terkait pemilihan metodologi ini dapat kita lihat dari artikel "Methodology Per Project". Menurut penulis artikel tersebut, Alistair Cockburn, metodologi memiliki sepuluh elemen dasar yaitu: roles, skills, activities, techniques, tools, teams, deliverables, standards, quality measures dan project values. Tidak semua metodologi mencakup semua elemen tersebut, semakin besar proyek maka harus semakin besar metodologinya artinya aspek elemen yang dicakup harus semakin lengkap. Hal tersebut bisa dilakukan dengan cara mengelaborasi beberapa metodologi.

Lebih jauh lagi, perusahaan seharusnya tidak hanya mendefinikan acuan metodologi tetapi sebuah common frame of reference yang mencakup [lihat artikel berikut]:

A common project management model.
Companywide project management training programs.
Project management career development.
Knowledge-sharing activities.

Project Value Mangement di PROPS

noreply@blogger.com (eJLp12) — Mon, 31 May 2010 07:54:00 +0000

Buat mengingatkan kita, dalam PMBOK, didefinisikan 9 Knowledge Areas yaitu:

Project Integration Management
Project Scope Management
Project Cost Management
Project Time Management
Project Risk Management
Project Quality Management
Project HR Management
Project Communication Management
Project Procurement Management

Adakah knowledge area yang lain yang didefinisikan di framework lain yang tidak ada di PMBOK? Ada, salah satunya adalah yang ada di PROPS atau PROPS-C yaitu Project Value Management yang terdiri dari:

Value Analysis
Value Definition
Value Control

PROPS adalah model/framework untuk project management yang dibuat dan digunakan Ericsson. Sayangnya model ini cukup tertutup, walaupun sebagian kecil penjelasannya bisa dibaca di http://www.semcon.se/spm/props/props_online_intro/xprops/en/x.pe.intro.html.

PROPS mengadopsi semua knowledge areas dari PMBOK dengan tambahan Project Value Management. Tapi sayangnya, di website semcon tersebut Project Value Management" juga tidak ada penjelasan detailnya.

Ada yang punya informasi lebih detail tentang Project Value Mangement di PROPS?

Apakah Project Value Management di PROPS sesuai dengan apa yang dimaksud dalam buku Cost and Value Management?

Sukseskah layanan 3G di Indonesia.

noreply@blogger.com (eJLp12) — Tue, 04 May 2010 16:34:00 +0000

Saat mulai booming-nya 3G di Indonesia dan juga dinegara lain di dunia, yang paling digembar-gemborkan adalah layanan multimedia terutama video call. Operator-operator seluler di Indonesia pun berlomba-lomba untuk tidak sekedar membangun jaringan akses 3G juga membuat layanan multimedia berbasis video teleponi yang berbasis jaringan circuit switched seperti layanan video portal.

Saat itu 3G tidak digembar-gemborkan sebagai layanan akses mobile broadband. Tapi yang terjadi adalah semakin populer layanan akses data 3G sebagai mobile broadband yang perlahan tapi pasti semakin banyak digunakan, apalagi dengan banyaknya produk modem 3G untuk laptop atau PC. Justru layanan seperti video call tidak banyak digunakan pelanggan, apalagi layanan video portal yang bisa dibilang sudah mati.

Akses data menggunakan jaringan telepon seluler malah lebih berkembang setelah adanya implementasi HSDPA, produk khusus data akses yang dikeluarkan oleh operator dan makin populernya BlackBerry dan Facebook.

Dengan fakta tersebut, bisa kita bilang 3G sukses sebagai layanan mobile broadband tapi berapakah biaya yang sudah dikeluarkan untuk meningkatkan kapabilitas jaringan agar bisa menjalankan video call dan membuat layanan video portal? Jika layanan itu bisa dibilang mati, berapakah biaya yang terbuang?

Dengan pengalaman itu dan banyak pengalaman ketidaksuksesan yang lain, operator seluler semakin berhati-hati dalam menginvestasikan uangnya untuk membuat layanan baru dan mengadopsi teknologi baru.

Femtocell

noreply@blogger.com (eJLp12) — Tue, 20 Apr 2010 08:05:00 +0000

Topik femtocell, mungkin topik hot yang belum pernah dibahas disini. Kenapa? Ketika mempelajari tentang femtocell terutama konsep dasarnya, saya pikir femtocell ini tidak akan "jalan" di Indonesia.

Saya belum akan membahas topik femtocell ini disini, tapi mungkin ada yang punya pandangan tentang arah perkebangan implementasi femtocell di Indoensia? Silakan memberi komentar sementara saya menyiapkan tulisan tentang femtocell :-)

Evolved Packet Core (EPC)

noreply@blogger.com (eJLp12) — Sat, 03 Apr 2010 13:36:00 +0000

Anda mungkin sudah tahu teknologi LTE (Long Term Evolution) yaitu teknologi terkini yang dipersiapkan untuk jaringan akses radio telekomunikasi bergerak yang merupakan jalur evolusi untuk 2G GMS dan 3G UMTS.

LTE dikembangkan agar dapat memenuhi standar 4G dengan kecepatan akses yang lebih tinggi dari HSDPA, HSPA+. Perubahan teknologi akses radio ini juga diikuti dengan core network dari provider telekomunikasi bergerak.

EPC adalah core network untuk mendukung teknologi LTE dengan konsep arsitektur All-IP, artinya jaringan tersebut menggunakan protokol IP yang berbasis packet dan tidak lagi menggunakan TDM/ATM. EPC dibuat dan distrandarisasi oleh 3GPP pada Release 8 dan terus dikembangkan hingga saat ini (Release 10). Studi pembuatan packet core network baru untuk LTE ini disebut System Architecture Evolution (SAE) dengan fokus sebagai berikut:

Arsitektur yang sederhana dan mendukung kecepatan transfer data yang tinggi
Merupakan jaringan All-IP
Mendukung jaringan akses paket apapun misalnya WiFi, WiMAX
Mendukung mobilitas, roaming
Dapat tetap bekerja atau saling tehubung (interworking) dengan legacy system misalnya PSTN, GSM, UMTS, CDMA dll.
Mendukung layanan real-time dan multimedia dengan Quality of Experince (QoE) yang baik

Berikut ini digambarkan posisi EPC pada arsitektur jaringan operator telekomunikasi bergerak.

[Gambar diambil dari sini]

Berbeda dengan core network pada generasi sebelumnya yaitu 2G dan 3G, pada EPC tidak dikenal pembagian CS (circuit switched) domain dan PS (packet switched) domain. Pada EPC hanya digunakan protokol berbasis paket (IP) dari perangkat pengguna ke eNodeB, sebutan base station pada LTE, lalu ke EPC dan ke service domain atau application domain dalam hal ini biasanya adalah IMS (IP Multimedia Subsystem).

Penggunakan IP ini sesuai dengan perkembangan konvergensi teknologi telekomunikasi atau arsitektur next generation network (NGN) yang telah dirumuskan oleh organisasi-organisasi telekomunikasi dunia, seperti ETSI/TISPAN, 3GPP, 3GPP2, ITU.

Berikut gambar EPC yang meperlihatkan konektifitas dengan akses radio 2G, 3G, Internet, PSTN dan PLMN.

Klik gambar untuk meperbesar

Elemen dari EPC terdiri dari:

Mobility Management Entity (MME)
Serving Gateway (SGW)
Packet Data Network (PDN) Gateway (PGW)
Policy & Charging Rule Function (PCRF)

Kemana arah evolusi jaringan operator telekomunikasi Indonesia?

noreply@blogger.com (eJLp12) — Thu, 01 Apr 2010 04:29:00 +0000

Menurut saya, evolusi arsitektur jaringan dari operator telekomunikasi bergerak terutama GSM sudah sangat jelas yaitu mengikuti standard dari 3GPP. Standard tersebut sudah mengantisipasi global market trend.

Tiga pilar pengembangan (enhancement) yang terefleksikan dalam standar yang dibuat 3GPP
adalah

Access network
Arsitektur core network
Service dan atau service layer

Perlu diketahui saat ini kebayanakan operator telekomunikasi bergerak di Indonesia memiliki core network dari implementasi standar 3GPP Release 4. Sedangkan jaringan aksesnya mengimplementasikan teknologi GSM, UMTS, HSDPA bahkan sudah ada yang menggunakan telkologi HSPA+.

Jadi jika dilihat dari domain core network dan service layer, apa yang harus diadopsi oleh operator telekomunikasi bergerak saat ini sesuai dengan standar 3GPP adalah menambahkan arsitektur IMS (Standar 3GPP Release 5).

Saya sendiri termasuk yang skeptik akan keuntungan implementasi IMS dalam waktu dekat. IMS yang sudah mulai dikembangkan tahun 2002 dan kemudian standarnya selesai tahun 2005 pada 3GPP Release 5, saat ini sudah banyak diimplementasikan di operator-operator telekomunikasi baik mobile maupun fixed di luar negeri. Jika kita melihat di berita-berita, implementasi IMS mungkin bisa dibulang sukses, tapi saya tidak yakin implementasi itu sudah membuat suatu nilai tambah yang besar. Tidak ada layanan-layanan yang jadi booming dan menghasilkan revenue besar, bahkan layanan VoIP lewat jaringan IMS pun belum banyak digunakan saat ini.

IMS yang distandarisasi pada 3GPP Release 5 pun masih terbilang terburu-buru, sehingga terus dikembangkan sampai sekarang. Standar dianggap cukup lengkap setelah Rel-5 adalah Release 8 yang dikeluarkan pada tahun 2008 dan sering disebut Common IMS dan hingga Rel-9 dan Rel-10 spesifikasi IMS masih terus dikembangkan. Jadi mungkin adopsi IMS yang banyak dilakukan di tahun 2006 dan 2007 bisa dibilang sangat terburu-buru.

Jika kita melihat teori hype cycle-nya Gartner, saat ini kemungkinan perkembangan implementasi IMS telah mencapai "peak of inflated expectation" dan "through of disillusionment" sehingga mudah-mudahan di tahun ini IMS mulai menemukan tempatnya sehingga satu atau dua tahun kedepan bisa mulai masuk tahap "plateau of productivity" seiring dengan dorongan dari teknologi LTE.

IMS memang dibuat untuk menggantikan arsitektur jaringan saat ini yang berbasis circuit switched menjadi packet switch (berbasis protokol IP). Tapi saya kira belum saatnya investasi pada circuit switch digantikan sepenuhnya dengan packet switch, bahkan untuk 5 tahun mendatang. Investasi operator pada infrastruktur jaringan circuit switched sudah cukup besar.

Oleh karena itu jika operator telepon bergerak punya visi mengimplementasikan IMS saat ini, sejujurnya menurut saya hanya akan jadi penting sebagai strategi marketing, bahwa operator tersebut menjadi operator terdepan dalam menggunakan teknologi baru.

Tapi jika operator adalah operator yang memiliki jaringan fixed, mobile atau mungkin layanan digital TV, layanan internet xDSL, maka IMS akan sangat berperan penting untuk menuju kearah arsitektur Fixed Mobile Convergence (FMC) atau Next Generation Network (NGN). Jadi benefit yang lebih besar dari IMS akan sangat dirasakan oleh operator jenis itu.

Selain itu yang menjadi penting dari IMS, menurut saya adalah bagaimana layanan-layanan dasar yang sudah ada sekarang dapat diekspos sehingga layanan-layanan baru bisa dibuat dengan mudah dan pihak ketiga bisa berperan banyak dalam membuat layanan-layanan baru tersebut. Untuk mengekspos layanan-layanan dasar yang ada tersebut tidak harus ditempuh dengan mengimplementasikan sepenuhnya arsitektur IMS tapi bisa dengan mengimplementasikan "service broker" (OSA/Parlay).

Untuk menggunakan IMS sebagai infrastruktur pengganti layanan dasar teleponi berbasis ciscuit switched pun perlu didukung oleh jaringan akses radio yang baik dengan kecepatan minimal HSDPA. Pada saat ini cakupan akses HSDPA dari operator Indoensia pun masih terbatas dan kualitanya belum baik. Oleh karena itu implementasi IMS sekarang hanya akan menjadikan IMS sebagai service framework dan belum menjadi core network, karena layanan dasar teleponi dan layanan supplementary yang standar (MMTel) belum layak dijalankan.

Deployment IMS.

Dari segi implementasi atau deploymentnya, IMS akan tergantung pada produk vendor, artinya akan tergantung dari kondisi existing jaringan yang dimiliki operator. Ada beberapa vendor yang bisa melakukan evolusi bertahap dengan hanya upgrade software dari produk softswitch atau media gateway sehingga lebih efisien.

Oleh karena itu operator perlu melakukan riset untuk analisis bagaimana produk-produk yang sudah digunakan bisa di-upgrade menjadi jaringan IMS dan menganalisis antara evolusi yang sudah dibuat oleh standard body dengan kondisi market dan kondisi existing network. Sehingga didapatkan arah pengembangan (evolusi) yang efisien dari segi biaya dan menghasilkan keuntungan yang besar.

Selain analisis, riset juga membutuhkan proof of concept dari layanan-layanan yang akan dibangun diatas arsitektur IMS. Kita bisa ambil contoh dari implementasi layanan-layanan baru dari operator lain di luar negeri yang sudah mengimplementasikan IMS. Tapi menurut saya itu hanya akan menjadi contoh yang mungkin tidak "menjual" disini, sehingga diperlukan ide-ide layanan lain yang lebih cocok untuk market Indonesia.

Tentu saja pandangan saya diatas perlu didiskusikan lebih lanjut dan bersifat debatable. Silahkan yang mau mengkritik atau memberikan pandangan lain.

Catatan:

Saya tidak membicarakan mengenai Evolved Packet Core (EPC) atau SAE (Service Architecture Evolution) yang merupakan tren terkini dari jaringan telkomunikasi untuk teknologi LTE, karena saya kira masih terlalu dini teknologinya untuk diimplementasikan. Dan IMS merupakan bagian yang masih penting dalam EPC karena IMS merupakan jaringan yang access network agnostic artinya IMS bisa saling bekerjasama dengan EPC.

Rich Communication Suite (RCS)

noreply@blogger.com (eJLp12) — Wed, 31 Mar 2010 15:25:00 +0000

Ketika melihat terminologi Rich Communication Suite (RCS) di sebuah halaman website tetang spesifikasi produk IMS saya sudah bisa menebak apa maksud dari RCS. Dalam pikiran saya saat pertama membaca istilah RCS adalah komunikasi multimedia. Ya, tertanya memang tidak jauh dari itu pengertiannya.

Istilah RCS sendiri sebenarnya diawali dari sebuah initiative atau konsorsium dari beberapa provider komunikasi dan vendor produk telekomunikasi pada Februari 2008. Press rilisnya bisa dilihat disini. Tujuan konsorsium tersebut adalah membuat fitur-fitur atau layanan komunikasi yang lebih kaya (rich communication) yang dapat saling beroperasi antar provider (interoperability) dengan berbasis pada standar yang ada. Selain itu juga bertujuan untuk memberikan petunjuk (guideline) untuk implementasi dan melakukan test layanan tersebut.

Awalnya fitur utama RCS didefinisikan sbb:

Enhanced Phonebook, with service capabilities and presence enhanced contacts information
Enhanced Messaging, which enables a large variety of messaging options including chat and messaging history
Enriched Call, which enables multimedia content sharing during a voice call

Pada bulan September 2008 kemudian GSMA mengambil alih initiative tersebut dengan lebih banyak superter. Kemudian GSMA membuat dokumen spesifikasi RCS. Informasi tentang RCS dari GSMA dapat dilihat di halaman introduction, bisa dilihat di halaman tersebut, fitur lain dari RCS adalah

Broadband access client and support for a multi-device environment so user access to services and applications will be possible from both mobile and fixed terminals (PCs)

Berdasarkan dokumen RCS release 3, group fitur RCS adalah:

Social presence information enhancements
Enhanced messaging
Network value added services (NVAS)
Content sharing enhancement
Broadband access (BA) enhancement

Dalam menspesifikasikan RCS, GSMA mengadopsi spesifikasi dari organisasi lain yang sudah ada seperti dari 3rd 3GPP, Open Mobile Alliance (OMA), Telecommunication Technology Committee RCS group (TTC RCSS).

Jadi intinya layanan RCS bukanlah sebuah layanan baru, tapi layanan yang sebenarnya sudah ada dan biasa kita gunakan lewat Internet. Seperti halnya kita saat ini menggunakan Yahoo! Messanger dimana kita bisa berkomunikasi dengan chat/teks, voice, video call dan juta saling bertukar gambar atau file. Layanan seperti itu diadopsi dalam komunikasi bergerak dimana jaringan telekomunikasi sudah menyatu dengan jaringan Internet dengan adanya IMS dengan mengedepankan interoperability dengan standar teknis yang terbuka.

RCS pada dasarnya akan dapat berjalan juga pada jaringan 3G dengan menggunakan jaringan CS dan PS, tapi tentu saja untuk beberapa layanan seperti video atau image share mungkin tidak dapat dilakukan.

Berikut gambaran arsitektur RCS yang disederhanakan yang memperlihatkan hubungan antara dua provider RCS.

Gambar diambil dari dokumen spesifikasi RCS R3 Technical Realization
[Klik gambar untuk memperbesar]

Keterangan gambar:

CS/PS GW adalah gateway yang digunakan untuk menjembatani antara CS voice dengan PS Voice (MMTel).
IPX = IP Packet Exchange
VS AS = Video Sharing Application Server
IMS = IP Multimedia Subsystem
XDMS = XML Data Management Server
DM = Data Management
DS = Data Synchronization
IM = Instant Messaging Server
Presence = Presence Server

Bisa kita lihat RCS tidak terlalu special tapi menjadi special karena istilah tersebut sebuah istilah 'jualan' (marketing) sehingga menjadi populer. Yang menjadi penting adalah interoperability atau interworking sehingga layanan dapat berjalan dari berbagai jaringan akses (2G, 3G, LTE, Broadband) dan dengan menggunakan berbagai perangkat.

Telecom Service Broker

noreply@blogger.com (eJLp12) — Fri, 12 Mar 2010 04:01:00 +0000

Tulisan dari LightReading berjudul "Telecom Service Broker" ini menarik untuk dibaca. Dalam artikel itu kita akan tau apa, bagaimana dan siapa yang membuat produk "telecom service broker."

Konsep telecom service broker memang sama dengan service broker yang ada di dunia IT atau Service Oriented Architecture (SOA) saat ini. Tapi perlu diingat kata pertama dalam judul itu (Telecom) membuat konteksnya agak lain.

Istilah service broker di area provider telekomunikasi ini mulai menjadi berita ketika beberapa produsen produk ini membentuk Service Broker Forum bulan Maret 2009 oleh Aepona, AppTrigger, Convergin, jNetX dan OpenCloud.

Pada dasarnya elemen telecom service broker dibuat untuk memberikan kemampuan pada operator telekomunikasi untuk melakukan konektifitas antar aplikasi, interaksi antar layanan, network orchestration dengan menggunakan standar 3GPP.

Telecom service broker juga mengadupsi konsep elemen Service Capability Interaction Manager (SCIM) dalam jaringan IMS. Perlu diketahui awalnya SCIM adalah konsep yang belum didefinisikan dengan jelas tapi sudah dituliskan pada standar IMS di 3GGP R7. Studi tentang service broker oleh 3GPP bisa dilihat di TR 23.810 Study on Architecture Impacts of Service Brokering yang merupakan bagian dari 3GPP R8.

Pada website Service Borker Forum, dijelaskan paling tidak fungsi utama dari service broker adalah

SCIM
IM-SSF
IN-IN Trigger Management
Protocol/Call Flow Management
Subscriber Data Management Interaction

Gambar berikut memperlihatkan posisi service broker seperti definisi yang dijerlaskan Service Broker Forum:

"A network element that efficiently manages service interaction and service composition and resides between the service layer and the converging network and is traditionally decoupled from the core switch and the service execution or service creation environment"

Gambar diambil dari Service Broker Webinar slide presentation

Seperti ditulis di artikel LightReading, :

"service-broker functionality has long existed in mobile networks, but that many operators were not translating this need into a defined product category"

Jadi konsep telecom service broker sejak lama dan sudah mulai diimplementasikan seiring dengan berkembangnya Parlay-X, IMS/SCIM, SDP, Next Generation IN, Telco 2.0, OneAPI dan API-API lain yang mengekspos jaringan/layanan operator telekomunikasi ke "dunia luar" (IT world/3rd parties/Internet). Dan saya pede untuk mengatakan kalo ini sebenarnya adalah strategi marketing vendor-vendor telekomunikasi yang punya produk tersebut untuk dapat menjual (atau istilah sopannya mengedukasi para customer dalam hal ini operator telekomunikasi).

Saya tidak yakin kalo operator-operator di Indonesia dalam waktu dekat akan migrasi ke MIS atau SIP dari tradisional signaling (SS7), jadi yang relevan buat operator-operator di Indonesia adalah telecom service broker yang mengekspos legacy system (seperti MSC, legacy IN, SMSC, HLR, dll) ke "dunia luar". Di beberapa operator juga banyak lebih memilih untuk mulai menggunakan SIGTRAN (SS7 over IP) dibanging migrasi menggunakan SIP.

Jadi dalam kasus telecom service broker ini yang akan jadi preferred choice di Indonesia adalah yang bisa mengekspos legacy system.

OSS/J

noreply@blogger.com (eJLp12) — Mon, 08 Mar 2010 11:38:00 +0000

OSS/J awalnya merupakan grup perusahaan-perusahaan yang berusaha membuat implementasi dari OSS/BSS dengan menggunakan Java sebagai teknologinya dan arsiteturnya mengacu pada NGOSS (Next Generation Operations Support System).

OSS/J dibentuk tahun 2003 dengan menggunakan Java Community Process (JCP) untuk membuat standar API yang dispesifikasikan pada dokumen JSR (Java Specification Request). Tahun 2006, OSS/J mulai bergabung dengan organisasi TMForum dan tahun 2008 mulai masuk dalam satu payung dalam TMForum Interface Program.

OSS/J API ini dibuat dengan beberapa teknologi untuk integrasi yang disebut integration profiles, yaitu Java RMI/IIOP, XML/JMS, dan Web Services.

Integration Profiles

[Gambar diambil dari dokumen OSSJ Design Guidelines]

Core API dari OOS/J ini didesain sesuai Core Business Entities (CBE) yang diadopsi dari Shared Information Data (SID) model yang dibuat oleh TMForum.

Awalnya API yang dibuat adalah sebagai berikut:

Common API v1.0
Inventory v1.0
Trouble Ticket v1.0

Kemudian berkembang menjadi beberapa API sebagai berikut:

Common API (JSR 144)
Service Activation v1.1(JSR 89)
Quality of Service v1.0 (JSR 90)
Trouble Ticket (JSR 91)
IP Billing (JSR 130)
Inventory API (JSR 142)

Hingga saat ini beberapa perubahan terlah terjadi yaitu

- Service Activation API diganti menjadi Order Management API.

- Billing Mediation atau IP Billing API dan Quality of Service API sudah tidak dikelola lagi.

- Bagian dari QoS API yaitu fault management dibuat terpisah menjadi Fault Management API.

Saat ini OSS/J API dikembangkan dengan prinsip SOA (Service Oriented Architecture) dengan spesifikasi sebagai berikut:

Common API v1.5 (JSR 144)
Order Management v1.0 (JSR 246)
Trouble Ticket v1.2 (JSR 91)
Inventory v1.2 (JSR 142)
Fault Management v1.0 (JSR 263)
Discovery v1.0 (JSR 254)

Dokumen spesifikasi tersebut bisa di-download disini (website TMForum) atau disini (website JSR).

TMForum juga mengembangan implementasi OSS/J yang gratis dan open source dan memberikan list beberapa produk yang sudah mengimplementasikan standar OSS/J.

VoLTE: VOLGA vs OneVoice Initiative

noreply@blogger.com (eJLp12) — Sat, 06 Mar 2010 00:21:00 +0000

Agak telat berita ini saya tulis disini, tapi masih cukup segar, belum lama ini GSMA merilis berita bahwa mereka mengadopsi One Voice sebagai teknologi Voice over LTE (VoLTE).

Seperti pada tulisan sebelumnya, cukup mengherankan kenapa ada inisiatif One Voice ini, padahal sudah ada VoLGA dan juga IMS. Tapi cukup jelas bagaimana posisi VoLGA terhadap One Voice ini seperti yang dilansir oleh VoLGA Forum bahwa operator telekomunikasi berhak menentukan bagaimana evolusi jaringannya dan

"VoLGA is an excellent solution for voice and SMS over LTE for operators who decide to take an interim approach prior to IMS-based voice and messaging services"

Dan saya percaya untuk kondisi Indonesia, VoLGA masih lebih cocok sebagai jalur yang perlu ditempuh --untuk menuju LTE-- oleh para operator telekomunikasi kita yang masih menggunakan jaringan berbasis circuit switch dan enggan untuk berevolusi ke IMS.

TOGAF 9

noreply@blogger.com (eJLp12) — Fri, 05 Mar 2010 05:14:00 +0000

Belum lama ini, 4 Februari 2010 telah dirilis TOGAF versi 9.

TOGAF merupakan singkatan The Open Group Architecture Framework yaitu framework maupun metodologi untuk arsitektur IT atau sering disebut Enterprise Architecture (EA). Bisa dikatakan TOGAF merupakan acuan (guide) untuk merancang atau membangun sebuah EA.

Dokumen TOGAF versi 9 bisa diunduh dari website The Open Group setelah melakukan registrasi.

Lagi lagi API untuk Telekomunikasi: OneAPI

noreply@blogger.com (eJLp12) — Tue, 02 Mar 2010 12:24:00 +0000

Seperti sudah dijelaskan sebelumnya, usaha untuk membuat API atau interface yang membuka layanan dari operator atau provider telekomunikasi telah dilakukan beberapa organisasi, salah satunya adalah OneAPI yang diusing oleh GSM Assosiation, sebuah organisasi atau asosiasi internasional yang beranggotakan operator/provider telekomunikasi GSM dan vendor telekomunikasi.

Awalnya proyek OneAPI ini dinamai 3rd party access, yang dari namanya sudah jelas tujuannya adalah membuat API untuk memberikan akses kepada pihak ketiga ke layanan atau network yang dimiliki operator telekomunikasi.

Saya tidak akan membahas terlalu jauh tentang OneAPI karena API ini belum lama muncul, belum mature dan informasi atau dokumentasinya pun masih sangat minim.

Proyek pilot secara komersialnya baru dilakukan bulan lalu (Februari 2010), sedangkan spesifikasi dan dokumentasinya baru akan dirilis bulan Maret 2010. Saat ini API ini baru menspesifikasikan fungsi-fungsi untuk Messaging (SMS and MMS), Location, Payments dengan tekonologi Web Service dan RESTful. Spesifikasi OneAPI ini kemungkinan akan dikeluarkan oleh OMA.

Rencananya, OneAPI versi 2 akan memasukan fungsi-fungsi berikut:

Data Connection profile
QoS Quality of Service
Remaining Credits Look-Up
SMS triggering via UDH
In-app billing

Lebih lanjut tentang OneAPI ini bisa dilihat di portal atau di library.

OneAPI: The first standard telecom RESTful API?

Saya sendiri bertanya-tanya mengapa dibuat standar baru dengan teknologi REST? Yang jelas REST ini lebih sederhana dibanding SOAP dan juga mudah karena menggunakan protokol HTTP.

Dan yang pasti beberapa vendor memang sudah mulai menggunakan REST sebagai interface untuk solusi SDP. Coba anda baca artikel "Who Makes What: RESTful Service Delivery Platforms". Bisa jadi RESTful API akan semakin banyak digunakan menggantikan SOAP seiring dengan makin populernya konsep Telco 2.0.

JAIN API

noreply@blogger.com (eJLp12) — Tue, 02 Mar 2010 04:14:00 +0000

JAIN adalah komunitas di JCP (Java Community Process) yang berinisiatif membuat standar API untuk keperluan pembuatan layanan (service) teleponi baik itu layanan yang berbasis suara maupun data.

Nama awal JAIN adalah Java APIs for Intelligent Network karena tujuan awalnya JAIN adalah membuat API untuk layanan Intelligent Network (IN), tetapi kemudian berkembang cakupannya menjadi API untuk semua service di jaringan telekomunikasi sehingga namanya diubah menjadi Java APIs for Integrated Networks.

Dibuatnya API untuk mengekspos layanan teleponi ini dilatarbelakangi oleh trend konvergensi dunia telekomunikasi dan dunia IT/Internet (layanan data). Dunia telekomunikasi selama ini dilandasi oleh protokol yang berbeda dengan yang digunakan di dunia IT yaitu protokol TCP/IP tapi serkarang mulai berkembang pemakaikan protokol TCP/IP di jaringan telekomunikasi. Untuk dapat memberikan layanan-layanan baru yang mudah dan cepat dibuat perlu suatu interface atau API.

Selain JAIN, inisiatif untuk membuat interface atau API juga dilakukan organisasi atau komunitas lain misalnya OSA/ParlayX yang dibuat Parlay Group, OneAPI [link portal] yang dibuat oleh GSM Association & Aepona.

Berikut adalah beberapa spesifikasi yang sudah dibuat oleh JAIN yang bisa juga dilihat disini atau disini:

1. Java Application Interfaces for Communications:

- JAIN SIP 1.1

- SIP API for J2ME 1.0

- JAIN MGCP 1.0

- JAIN MEGACO

- JAIN Session Description Protocol (SDP)

- JAIN ENUM [lihat RFC2916]

- JAIN TCAP 1.1

- JAIN INAP 1.0

- JAIN Java Call Ccontrol (JCC) 1.1

- JAIN Java Coordination and Transaction (JCAT)

- Java Payment API (JPay)

- JAIN Presence

- JAIN Instant Messaging

- JAIN SIMPLE Instant Messaging

- JAIN SIMPLE Presence

- JAIN SIP Lite

- JAIN Service Creation Environment (SCE) SCML

- JAIN Service Creation Environment (SCE)

- Java - Server API for Mobile Services (SAMS): Messaging

2. Java Application Containers for Communications:

- JAIN Service Logic Execution Environment (JSLEE)

- SIP Servlets 1.0

Cukup banyak spesifikasi interface yang sudah dibuat oleh JAIN. Tapi perkembangan market penggunaan JAIN API maupun API sejenis di operator telekomunikasi saat ini saya kira masih rendah.

Operator telekomunikasi tidak perlu lagi WAP Gateway?

noreply@blogger.com (eJLp12) — Mon, 01 Mar 2010 02:50:00 +0000

Produk-produk WAP Gateway atau WEB proxy yang digunakan operator telekomunikasi biasanya memiliki fitur penting yaitu

kompresi, sehingga trafik ke internet menjadi semakin efektif (kecil)
adaptasi kontent atau tampilan, yang membuat tampilan di mobile device menjadi sesuai dengan kapabilitasmobile device tersebut atau aplikasi web/wap browser-nya.

Tapi dengan adanya beberapa perusahaan yang memberikan layanan gratis untuk fungsi tersebut, fitur tersebut menjadi tidak penting buat sebuah WAP Gateway atau WEB Proxy.

Sebagai contoh misalnya Google, perusahaan ini memberikan layanan adaptasi tampilan. Coba saja search pada google dari browser handphone anda dan klik hasil pencariannya, Google akan menubah tampilannya, jika halamannya panjang maka halaman akan dipotong dalam beberapa halaman.

Contoh lain yang mirip adalah Opera Mini yang memiliki strategi bisnis yang bagus yaitu bekerja sama dengan operator untuk memberikan layanan browsing yang lebih efisien dan murah tapi mereka (Opera) juga dapat untung.

Gambar dari Opera.com

Dengan menggunakan aplikasi browser Opera Mini, aktifitas browsing tidak lagi langsung mengakses web server yang dituju, tetapi akses koneksi akan dilewatkan ke Opera Mini Server yang bertugas untuk melakukan optimasi seperti kompresi dan adaptasi konten. Jadi Opera Mini Server berfungsi sebagai proxy atau gateway default untuk aplikasi browser Opera Mini.

Mekanisme tersebut membuat akses internet menjadi optimal dan efisien baik dari sisi pengguna (pelanggan) maupun dari sisi operator telekomunikasi. Oleh sebab itu bisnis ini bisa dilirik oleh operator.

Berikut link yang menjelaskan pemaparan teknologi Opera Mini.

Terminologi komersial perjanjian sales

noreply@blogger.com (eJLp12) — Thu, 03 Dec 2009 11:34:00 +0000

Seringkali seorang project manager harus berhubungan dengan pengadaan atau pembelian barang atau jasa dari pihak ketiga untuk keperluan proyek. Oleh karena itu pengetahuan tentang aspek komersial sangat diperlukan termasuk istilah-istilah yang digunakan secara umum untuk perdagangan sehingga kita tau resiko-resiko perdagangan atau pengiriman barang dan terhindar dari biaya-biaya yang tidak diketahui. Ingat, dalam PMBOK, "Procurement Management" merupakan bagian dari Project Management yang perlu kita kuasai juga.

Dalam pengadaan barang/jasa dokumen yang biasa digunakan adalah Purchase Order (PO), Bill of Quantity (BoQ) dan atau Bill of Material (BoM). Salah satu hal yang perlu diperhatikan dalam BoM adalah biaya transfer atau pengiriman, biaya resiko pengiriman, dan biaya pajak. Istilah-istilah yang digunanakan dalam pengiriman internasional biasaya mengacu pada INCOTERMS 2000. Incoterms adalah singkatan dari International Commercial Terms.

INCOTERMS 2000 adalah kumpulan istilah-istilah dalam perdangan yand dibuat oleh International Chamber of Commerce untuk tujuan kesamaan pengertian antara penjual dan pembeli. Penting buat kita untuk mengerti istilah-istilah ini terutama jika berhubungan dengan pengiriman dari atau ke luar negeri (export/import)

Istilah-istilah tersebut adalah:

Group E Incoterms (departure)

EXW (Ex works)

Group F Incoterms (main carriage unpaid)

FCA (Free carrier)
FAS (Free alongside ship)
FOB (Free on board)

Group C Incoterms (main carriage paid)

CFR (Cost and freight)
CIF (Cost, insurance and freight)
CIP (Carriage and insurance paid to)

Group D Incoterms (arrival)

DAF (Delivered at frontier)
DES (Delivered ex ship)
DEQ (Delivered ex quay)
DDU (Delivered duty unpaid)
DDP (Delivered duty paid)

Saya tidak akan menjelasan masing-masing istilah itu disini karena anda dapat baca di wikipedia Indonesia atau disini

One Voice Initiative

noreply@blogger.com (eJLp12) — Fri, 13 Nov 2009 13:24:00 +0000

Cukup tercengang juga baca berita belum lama ini tentang One Voice Initiative, sebuah inisiatif untuk mendefisikan teknis layanan voice dan sms pada jaringan LTE.

Cukup heran karena membuat saya bertanya apalagi yang mereka (vendor-vendor dan operator-operator telekomunikasi dan para pembuat ponsel) perbuat ini?

Setelah VoLGA yang dibuat oleh beberapa vendor dan operator yang berbeda, 3GPP setidaknya memiliki jawaban atas pertanyaan apa yang harus dilakukan oleh operator untuk layanan voice dan sms dalam jaringan LTE dan continuity process layanan tersebut pada jaringan circuit-switched. Tapi sekarang beberapa vendor dan operator malah membuat inisitiatif baru untuk solusi layanan voice dan sms dalam jaringan LTE? Apa yang berbeda?

Setelah beberapa saat menyempatkan baca beberapa berita yang sama diberbagai website, seperti yang diungkapkan NSN, ternyata One Voice ini tidak membuat standar baru, tapi tetap menggunakan standar 3GPP yang berarti berbasiskan IMS atau VoIP. One Voice ini bertujuan memberikan kemudahan bagaimana deployment solusi telknologi layanan voice/sms pada jaringan LTE dengan menyelesaikan isu-isu seperti roaming dan interworking dan menjamin kompabilitas antar jaringan-jarangn serta devices (ponsel) dengan membuat common profile. Common profile merupakan pendefinisian sebuah himpunan dari fungsi-fungsi minimum yang telah dibuat 3GPP untuk digunakan oleh vendor-vendor dan para operator.

Beberapa aspek yang ada dalam cakupan OneVoice ini adalah:

• IMS basic capabilities and supplementary services for telephony
• Real-time media negotiation, transport, and codecs
• LTE radio and evolved packet core capabilities
• Functionality that is relevant across the protocol stack and subsystems

Berikut ini gambar protokol stack yang digunakan pada solusi OneVoice:

Pada level TCP/IP digunakan protokol UDP, level SIP digunakan jg SDP, RTP, RTCP dan pada level HTTP digunakan juga XCAP (lihat 3GPP TS 24.623: "Extensible Markup Language (XML) Configuration Access Protocol (XCAP) over the Ut interface for Manipulating Simulation Services").

Lebih lanjut mengenai detail teknis OneVoice dapat dibaca pada dokumen One Voice profile.

Kenapa kita butuh VoLGA?

noreply@blogger.com (eJLp12) — Wed, 11 Nov 2009 12:57:00 +0000

Pertanyaanya sebenernarnya adalah kenapa vendor-vendor membuat spesifikasi VoLGA yaitu spesifikasi atau standar untuk layanan circuit-swirched seperti voice dan SMS di jaringan LTE. Apakah memang 3GPP tidak membuat standar untuk itu sehingga perlu forum baru yang membuat standar ini?

Pertanyaan berikutnya adalah apakah dengan didukungnya standar VoLGA ini oleh perusahaan-perusahaan besar akan membuat VoLGA digunakan secara luas dan membuat standar ini pada akhirnya, mau tidak mau, akan diadopsi oleh 3GPP?

Sebelum mencari jawaban pertanyaan-pertanyaan itu mari kita pelajari lebih dalam 'apa', 'bagaimana' dan 'kenapa'-nya VoLGA.

VoLGA (Voice over LTE via Generic Access) adalah istilah yang merujuk pada standar atau spesifikasi yang dibuat VoLGA Forum yang dibuat untuk memberikan alternatif baru cara untuk menggunakan layanan tradisional berbasis circuit-based pada jaringan GSM maupun UMTS pada jaringan LTE.

Buat pengguna layanan telepon selular, telnologi VoLGA akan memberikan konsistensi layanan suara, SMS dan layanan-layanan lain berbasis circuit-switched saat terjadinya transisi antara jaringan akses radio GSM, UMTS dan LTE. Sedangkan buat operator, diharapkan dengan adanya VoLGA akan memberikan solusi yang murah dan sedikit resiko untuk mulai mengadopsi jaringan akses LTE tanpa harus kehilangan layanan utama yang memberikan keuntungan yang paling besar yaitu layanan suara dan SMS.

Begitulah yang dijanjikan VoLGA Forum.

VOLGA merupakan standar yang terbuka, dokumen spesifikasi dapat di-download dari website VOLGA Forum. Dokumen spesifikasi terdiri dari bagian yaitu (1) Requirement, (2) Architecture dan (3) Protocol.

Untuk mengetahui lebih detail mengenai VOLGA, silahkan baca whitepaper yang dibuat oleh penulis blog WirelessMoves ini.

Apakah di jamannya LTE nanti, circuit-switched network akan hilang?

noreply@blogger.com (eJLp12) — Wed, 11 Nov 2009 12:31:00 +0000

Jawaban singkatnya: Tidak.

Sudah terlalu mapan jaringan yang berbasis ciscuit-swich dan layanannya, sudah banyak yang diinvestikan untuk jaringan tersebut, oleh karena itu LTE tidak akan cepat menggesernya.

VoIP memang sudah banyak digunakan saat ini, tapi kualitas (QoS) dari layanan ini masih dianggap belum memuaskan dibandingkan layanan voice tradisional. VoIP merupakan dasar layanan voice pada IMS, tapi kenyataannya belum banyak operator yang menggunakan IMS. Setidaknya, dibandingkan dengan waktu saat IMS rilis sebagai standar 3GPP, waktu adopsi IMS oleh operator jaringan nirkabel sangatlah lambat. Di Indonesia saja setahu saya belum ada operator yang mulai menggunakan IMS secara penuh, apalagi untuk layanan voice-nya.

Mitos, LTE hanya untuk traffic data jadi sangatlah wajar, mengingat jaringan core LTE (SAE) dibangun dengan basis jaringan paket (IP) dan alasan yang saya jelaskan diatas.

Roaming call flow: MSRN (Mobile Station Roaming Number)

noreply@blogger.com (eJLp12) — Tue, 12 May 2009 12:30:00 +0000

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)

noreply@blogger.com (eJLp12) — Tue, 05 May 2009 06:29:00 +0000

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

noreply@blogger.com (eJLp12) — Tue, 28 Apr 2009 01:34:00 +0000

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

Product Engineering
Requirement, Design, Code and Unit Test, Integration and Test, Engineering Specialities
Development Environment
Development Proceds, development System, Management Process, Management Methods, Work Environment
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

TAM (Technical Achitecture Modeling) = FMC + UML

noreply@blogger.com (eJLp12) — Thu, 02 Apr 2009 06:27:00 +0000

Buat anda yang sering mendesain software, tentu sudah terbiasa dengan menggunakan diagram untuk menggambarkan arsitektur dari sistem yang dibangun. Anda pasti kenal UML (Unified Modeling Language). Jika anda merasa bahwa UML tidak cukup representatif untuk menggambarkan konsep arsitektur sistem yang akan dibangun, tenang saja anda tidak sendiri.

Sudah banyak orang setuju bahwa UML cukup representatif untuk menggambarkan detail desain. Tapi untuk menggambarkan arsitektur, mungkin ada baiknya anda menengok FMC (Fundamental Modeling Concept), sebuah alternatif untuk mengambarkan diagram arsitektur, hubungan antar module/elemen dan flow proses.

Dibawah ini adalah gambar yang mengilustrasikan dimana FMC "mengisi batas" antara proses perancangan architecture dengan detail design dalam proses pembangunan software.

FMC seperti halnya UML memiliki beberapa jenis diagram, untuk menggambarkan arsitektur pada tataran konsep (high level) anda bisa gunakan block diagram.

Block diagram pada FMC bersama-sama dengan diagram lain dalam UML telah menjadi standar dalam perusahaan SAP dan diberinama TAM (Technical Achitecture Modeling). Berikut ini contoh sebuah block diagram:

Gambar diambil dari artikel "How to communicate architecture – Technical Architecture Modeling at SAP"

Berikut beberapa artikel tentang TAM:

Standardized Technical Architecture Modeling, Conceptual and Design Level
How to communicate architecture – Technical Architecture Modeling at SAP (part 1 & Part 2)

Beberapa tools untuk menggunakan TAM:

HSDPA

noreply@blogger.com (eJLp12) — Tue, 10 Mar 2009 02:56:00 +0000

HSDPA (High Speed Downlink Packet Access) merupakan pengembangan dari arsitektur WCDMA yang dispesifikasikan pada standar 3GPP Release 5. Dengan HSDPA, secara teori, maksimum kecepatan transfer downlink data (peak data rate) dapat mencapai 14.4 Mbps dari yang sebelumnya hanya mencapai 384 kbps.

Implementasi HSDPA pada jaringan operator memerlukan perubahan terutama pada Radio
Access Network (RAN) yaitu pada Node B, RNC dan juga User Equiptment (UE).

Beberapa teknologi kunci HSDPA yang merupakan pengembangan dari teknologi sebelumnya adalah:

Adaptive modulation and coding (AMC)

AMC berarti modulasi yang digunakan, jumlah kode dan code rate dioptimasi selama koneksi dengan memperhitungkan channel quality information (CQI) yang diterima dari perangkat pengguna (UE) modulasi yang digunakan misalnya QPSK, 16QAM

Channel coding digunakan untuk memperbaiki kesalahan (error) yang terjadi saat transmisi ataupun saat penerimaan sinyal radio di udara. Pada versi sebelumnya, sistem coding yang digunakan adalah half rate convolutional coding, 1/3 convolutional coding atau 1/3 turbo coding. Pemilihan jenis coding yang digunakan dilakukan oleh RNC dan berubah (dinamic) tergantung dari kondisi channel.

Beberapa vendor alat telekomukasi memilih untuk melakukan pemilihan coding scheme di BTS agar adaptasi terhadap kondisi channel lebih cepat. Contoh penggunaan coding scheme yang berbeda dengan modulasi yang sama misalnya QPSK1/4, QPSK2/4, QPSK3/4.

Selain adaptasi coding scheme, perubahan modulasi juga dilakukan berdasarkan kondisi channel. Misalnya modulasi dengan coding scheme yang berbeda-beda yang digunakan adalah QPSK1/4 QPSK2/4 QPSK3/4 16QAM2/4 16QAM3/4.

Perubahan modulasi dan coding scheme yang berbeda ditentukan dari carrier-to-interference ratio yang diterima dari UE.

Teknologi AMC ini menggantikan fitur variable spreading factor (SF) dan fast power control yang merupakan fitur dasar dari WCDMA.

Fast scheduling

Peningkatan pada transmission time interval (TTI) dan Node B menangani penjadwalan paket. Setiap TTI, packet scheduler di BTS melakukan pemilihan sebuah perangkat pengguna (UE) yang akan dilayani.

Fast retransmission

Peningkatan kecepatan retransmisi ini adalah akibat langsung dari penanganan data retransmisi oleh BTS pada layer 1. Pada rilis sebelumnya, retransmisi dilakukan oleh Radio Network Controller dengan menggunakan Radio Link Control (RLC).

Retransmisi dilakukan jika transmisi radio ataupun proses decoding data tidak berhasil sehingga UE mengirimkan informasi NACK. Pada layer 1, proses Hybrid Automatic Retransmission reQuest (HARQ) digunakan untuk mentranmisikan informasi yang benar ke UE.

Retransmisi pada layer RLC maupun TCP masih dimungkinkan juga terjadi pada HSDPA.

Pada teknologi HSDPA, diperkenalkan juga beberapa radio channel baru pada interface Uu yaitu:

- Transport channel HS-DSCH
- Physical channel, yaitu:
> HS-PDSCH, physical channel yang digunakan untuk membawa HS-DSCH
> HS-DPCCH yang digunakan untuk membawa uplink control data
> HS-SCCH yang digunakan untuk membawa dowlink control data

HSDPA data dibawa oleh HS-DSCH yang merupakan shared channel dimana data dari setiap user yang dilayani oleh sebuah cell dikirimkan. Oleh karena itu, pada jaringan HSDPA throughput yang dirasakan oleh end user bergantung dari banyaknya user yang dilayani oleh cell yang sama.

Pada HSDPA, interface Iub juga mengalami efisiensi karena menggunakan time-shared channel untuk membawa data. Hal ini dimungkinkan karena HSDPA tidak mendukung soft handover.

Implementasi HSDPA pada jaringan UMTS berpengaruh pada elemen BTS/Node B dan RNC, terutama memerlukan updagrade baik hardware maupun software. Detil keperluan implementasi HSDPA pada existing network dapat dilihat pada gambar dibawah ini.

Lebih lanjut tentang HSDPA dapat dibaca pada spesifikasi berikut:

3GPP TS 25.855 High Speed Downlink Packet Access (HSDPA); Overall UTRAN description
3GPP TS 25.856 High Speed Downlink Packet Access (HSDPA); Layer 2 and 3 aspects
3GPP TS 25.876 Multiple-Input Multiple-Output Antenna Processing for HSDPA
3GPP TS 25.877 High Speed Downlink Packet Access (HSDPA) - Iub/Iur Protocol Aspects
3GPP TS 25.890 High Speed Downlink Packet Access (HSDPA); User Equipment (UE) radio transmission and reception (FDD)