BROOM KALONG

Paket ini cocok banget buat kamu yang suka internetan semalaman suntuk sampai subuh. IM2 Broom Kalong..
Bisa download banyak lagu, film dan lainnya dengan kuota yang besar..

Jenis Voucher	Harga Voucher	Nilai Voucher	Masa Aktif	Masa Tenggang
Starterpack Broom Kalong	Rp 150.000	Rp 100.000	1 Bulan	60 hari
Voucher Isi Ulang/Top up	Rp 100.000	Rp 100.000	1 Bulan	60 hari

• Pengaturan kecepatan akses dan threshold berlaku pada jam 00.00 s/d 06.00
• Pelanggan akan menikmati akses internet tanpa batasan volume dengan pembatasan kecepatan akses pada pukul 06.01 s/d 23.59

Ketentuan :

• Harga Starterpack/Perdana Rp 150.000
• Terdiri dari fitur Classic dan Unlimited
• Proses Registrasi dilakukan oleh pelanggan

Broom Kalong Fitur Classic :

• Kecepatan Akses <3.6bps
• Multiple Akses
• Tarif Broom Classic
  

  Tarif Broom Classic
  Jenis Voucher	Harga	Nilai	Quota	Masa Aktif	Masa Tenggang
  SP Broom Kalong	Rp 150.000	Rp100.000	200 MB	60 Hari	90 Hari
  Voucher isi ulang	Rp 150.000	Rp150.000	300 MB	60 Hari	90 Hari
  Voucher isi ulang	Rp 100.000	Rp 100.000	200 MB	45 Hari	90 Hari
  Voucher isi ulang	Rp 50.000	Rp 50.000	100 MB	30 Hari	90 Hari
  Voucher isi ulang	Rp 50.000	Rp 50.000	50 MB	25 Hari	90 Hari
  Voucher isi ulang	Rp 10.000	Rp 10.000	20 MB	7 Hari	90 Hari

• Bonus Kuota 100% jika pelanggan melakukan isi ulang dengan nominal voucher Rp100.000 (Bonus Kuota ini berlaku hingga 31 Desember 2010)

Broom Kalong Fitur Unlimited :

• Unlimited adalah fitur atau layanan dengan harga tetap, tanpa batasan volume pada periode masa aktif
• Single Akses
• Threshold sebesar 5 GB
• Isi Ulang per Bulan Rp 100.000
• Masa Aktif 1 bulan
• Masa Tenggang : 60 hari
• Kecepatan Akses Pukul 00.00 s/d 06.00 WIB adalah 1 Mbps s/d threshold 5 GB.
  Setelah melewati Threshold 5GB kecepatan akses <>
• Kecepatan akses Pukul 06.01 s/d 23.59 WIB adalah 16 Kbps

Dengan Broom Kalong Unlimited, kamu bisa mengaktifkan fitur Turbo Speed. Yuk cobain ngebut pake Turbo Speed.. Klik di sini yaa

Ada lagi lhoo yang baru dari IM2, yaitu Broom Peket Asik Unlimited. Cek infonya di sini!!!

Isi Ulang dan Top Up Broom kamu bisa dengan banyak cara :

1. Bisa dengan membeli Voucher Indosat (IM3, Mentari dan StarOne) dan Voucher IM2 lebih dulu.
2. Lalu top up di www.indosatm2.com/topup.
3. Kamu bisa cek topup kamu berhasil atau gagal di : Member Zone Login. Klik aja https://www.indosatm2.com/index.php/secure-login
4. Via SMS dari No Indosat juga bisa. Caranya : ketik “im2pre(spasi)nilainominal kirim ke 6789.
5. Isi ulang via ATM (ATM Bersama, Bank mandiri, Prima, Alto, Panin, Permata, BNI, dan BCA) dan kamu tinggal ikutin langkah-langkah dari Bank tersebut.
6. Internet Banking Permata : kamu masuk ke www.permatanet.com lalu ikuti setiap petunjuknya.
7. SMS Banking Mandiri : im2pre(spasi)username(spasi)nilainominal kirim ke 9779.
8. Via ISEV (Indosat Electronic Voucher) tinggal topup dari reseller dan berikan Customer ID Broom kamu.
9. Mobile Top Up : http://m.indosatm2.com
10. Website IM2 di www.indosatm2.com/topup
11. Jika salah satu cara di atas sudah kamu lakukan, jangan lupa cek pulsa Broom kamu sudah bertambah atau belum. Cek di sini ya https://www.indosatm2.com/index.php/secure-login

Dapatkan Paket Broom Kalong ini di :

• IM2 Galeri (WIC/IBC) Klik di sini
• Oulet-Oulet Mitra IM2 Klik di sini

Broom Bursa Internet IM2

Nikmati Akhir Tahun Baru Seru Bersama IM2.. Dan Dapatkan Bonus Akhir Tahun Yang Melimpah..... Untuk pelanggan Broom fitur Unlimited, kamu bisa puas internetan dengan quota yang makin besar!!! Broom Bastis 3GB ==> 5GB* Broom Paket Merdeka 150MB ==> 250MB* Broom Xtra2 500MB ==> 1.5GB*

Untuk pelanggan Broom fitur Classic, kamu bisa nikmati Bonus Quota 100% setiap kamu isi ulang sebesar Rp 100.000

Masih ada lagi promo yang bisa kamu nikmatin.. yaitu fitur Turbo Speed. Fitur ini ditujukan khusus untuk kamu pelanggan Broom Unlimited.

Dengan Fitur Turbo Speed, kamu bisa memacu speed Broom kamu ke kecepatan yang lebih tinggi dari kecepatan biasanya. Untuk mengaktifkan fitur ini, kartu Broom kamu harus dalam masa aktif dan mempunyai Saving Balance (saving balance adalah saldo sisa topup paket unlimited yang belum digunakan, yang biasanya dialokasinya untuk memperpanjang masa aktif bulan berikutnya).

Fitur Turbo Speed
Tariff	Periode	Rp/KB	Kecepatan	Quota Normal	Qouta Promo
Rp 10.000	1 hari	0.39	<>	25 MB	50 MB
Rp 25.000	3 hari	0.33	<>	75 MB	150 MB
Rp 50.000	10 hari	0.24	<>	200 MB	400 MB
Rp 100.000	14 hari	0.22	<>	450 MB	900 MB

Mau coba internet ngebut dengan fitur Turbo Speed??? Klik di sini dulu yuk

*Promo Quota berlaku mulai 1 November hingga 31 Desember 2010

BROOM TURBO SPEED

Merupakan fitur tambahan yang disediakan bagi pelanggan Broom Unlimited yang memungkinkan pelanggan mendapatkan kecepatan akses internet lebih tinggi dari kecepatan akses unlimited biasanya. Untuk mengaktifkan fitur ini, kartu Broom anda harus dalam masa aktif dan mempunyai Saving Balance (saving balance adalah saldo sisa topup paket unlimited yang belum digunakan, yang biasanya dialokasinya untuk memperpanjang masa aktif bulan berikutnya). Aktivasi fitur Turbo Speed tidak akan mengganggu Unlimited Balance Pelanggan.

Cara Aktivasi :

Terdapat 2 cara untuk melakukan aktivasi Turbo Speed :

• Masuk ke Member Zone Login. Terdapat menu Turbo Speed di sebelah kanan layar.
• Masuk ke : http://www.indosatm2.com/turbo

Ketentuan :

Setelah mengaktifkan fitur Turbo Speed, maka pelanggan harus memutuskan koneksi internetnya terlebih dahulu. Setelah kembali melakukan koneksi, maka fitur Turbo Speed baru mulai dihitung aktif. Layanan Turbo Speed Pelanggan akan berakhir dalam kondisi berikut ini :

• Kuota Turbo Speed Pelanggan sudah habis
• Periode Turbo Speed Pelanggan sudah berakhir. Dalam kondisi ini, sisa kuota pelanggan akan hangus.
• Layanan Broom (Bastis, Xtra2, Merdeka, dll) masuk ke awal periode masa aktif bulan berikutnya. Dalam kondisi ini, periode Masa Aktif Turbo Speed akan berakhir dan sisa kuota Turbo Speed Pelanggan akan hangus.

Fitur Turbo Speed
Tariff	Periode	Quota	Rp/KB	Kecepatan
Rp 10.000	1 hari	25 MB	0.39	up to 3.6 Mbps
Rp 25.000	3 hari	75 MB	0.33	up to 3.6 Mbps
Rp 50.000	10 hari	200 MB	0.24	up to 3.6 Mbps
Rp 100.000	14 hari	450 MB	0.22	up to 3.6 Mbps

Ilustrasi Aktivasi Turbo Speed :

Keterangan ilustrasi :

1. Pelanggan meng-aktifkan Turbo Button senilai Rp 100.000, maka Pelanggan berhak mendapatkan :
   a. Kuota Turbo Speed sebesar 450 MB.
   b. Periode Masa Aktif Turbo Speed selama 14 hari.
2. Namun, karena layanan Broom Pelanggan memasuki awal periode masa aktif bulan berikutnya maka fitur Turbo Speed pelanggan akan berakhir. Sisa kuota Turbo Speed pelanggan akan hangus. Pelanggan akan menikmati Threshold baru dari layanan Broom dengan kecepatan akses 256 Kbps.
3. Status Balance Pelanggan Tgl 5 Januari 2010
   Unlimited Balance : Rp 200.000/Kuota 5GB
   Saving Balance : Rp 400.000
   Saving Balance ini bisa digunakan untuk memperpanjang masa aktif selama 2 bulan berikutnya (Feb dan Maret)
4. Status Balance Pelanggan Tgl 4 Februari 2010
   Unlimited Balance : Rp 200.000/Kuota 5GB
   Saving Balance : Rp 200.000
5. Status Balance Pelanggan Tgl 28 Feb 2010
   Unlimited Balance : Sisa kuota pelanggan tinggal 1 GB
   Saving Balance : Rp 100.000
   Turbo Balance : Rp 100.000

Note :

• Pelanggan dapat mengaktifkan fitur Tubo Button kapanpun mereka butuhkan selama memiliki Saving Balance yang cukup.
• Jika Saving Balance mereka tidak cukup atau nol, maka pelanggan bisa melakukan Top up sebesar yang mereka butuhkan untuk mengaktifkan Turbo Button.
• Jika layanan Broom Anda memasuki masa tenggang, maka TopUp yang Anda lakukan akan mengaktifkan layanan Broom Anda.
• Fitur Turbo Button memiliki kuota tersendiri yang terpisah dari layanan Broom. Jika Kuota Turbo Button Anda habis, maka Anda akan menikmati sisa kuota layanan Broom yang terakhir.
• Jika Anda masih memiliki sisa kuota layanan Broom pada saat Turbo Button diaktifkan, maka kecepatan akses Anda adalah up to 256
• Turbo Speed tidak mempercepat threshold unlimited (karena balance Unlimited dengan balance Turbo Speed dipisah)
• Pelanggan yang Turbo Speed nya belum habis, tidak bisa memilih paket Turbo Speed baru hingga Quota Turbo Speed habis atau masa aktif Turbo Speed berakhir.
• Apabila masa aktif Turbo Speed yang dipilih lebih panjang dari masa aktif Unlimited, maka yang berlaku adalah masa aktif Unlimited.
• Ketika quota Turbo Speed habis pelanggan akan di-redirect ke halaman Reminder sebagai reminder apabila threshold Unlimited tercapai, sehingga pelanggan harus melakukan diskonek dan koneksi ulang.

Fungsi String PHP

• AddSlashes

Digunakan untuk menambahkan karakter backslash ( \ ) pada suatu string. Hal ini penting digunakan pada query string untuk database, misalkan pada MySQL. Beberapa karakter yang akan ditambahkan tanda backslash adalah karakter tanda petik satu ( ‘ ), karakter petik dua ( “ ), backslash ( \ ) dan karakter NULL.

Sintaks: addslashes(string)

• StripSlashes

Digunakan untuk menghilangkan karakter backslash ( \ ) pada suatu string.

Sintaks: string stripslashes(string)

• Crypt

Digunakan untuk meng-encrypt dengan metode DES suatu string. Fungsi ini sering digunakan untuk mengacak string password sebelum disimpan dalam database. Dalam penggunaan fungsi crypt ini dapat ditambahkan parameter string ‘salt’. Parameter ‘salt’ ini ditambahkan untuk menentukan basis pengacakan. ‘Salt’ string terdiri atas 2 karakter. Jika ‘salt’ string tidak ditambahkan pada fungsi crypt maka PHP akan menentukan sendiri ‘salt’ string tersebut secara acak.

Sintaks: crypt(string [ , salt ] )

• Echo dan Print

Digunakan untuk mencetak/menampilkan isi suatu string/teks atau argumen ke browser.

Sintaks:

echo( string argumen1, string argumen2 , ….)

print( string argumen1, string argumen2 , ….)

• Explode

Digunakan untuk memecah-mecah suatu string berdasarkan tanda pemisah tertentu dan memasukkan hasilnya kedalam suatu variable array.

Sintaks: explode(string pemisah , string [, int limit] )

Contoh:

$namahari = “minggu senin selasa rabu kamis jumat sabtu”;

$hari = explode(“ ”, $namahari);

• Implode

Kegunaan fungsi ini adalah kebalikan daripada fungsi explode. Fungsi implode digunakan untuk menghasilkan suatu string dari masing-masing elemen suatu array. String yang dihasilkan tersebut dipisahkan oleh suatu string telah yang ditentukan sebelumnya.

Sintaks: implode(string pemisah , array)

• StripTags

Digunakan untuk menghilangkan kode-kode tag HTML pada suatu string.

Sintaks:

striptags(string [, string tags yang tidak dihilangkan] )

• StrLen

Digunakan untuk menghitung jumlah karakter suatu string.

Sintaks: strlen(string)

• StrPos

Digunakan untuk mencari posisi suatu sub string pada suatu string. Fungsi ini biasanya digunakan untuk mencari suatu sub string didalam suatu string.

Sintaks: strlen(string , sub string)

• Str_Repeat

Digunakan untuk mengulang isi suatu string.

Sintaks: str_repeat(string , int jumlah perulangan)

• Str_Replace

Digunakan untuk mengganti suatu string dengan string yang lain.

Sintaks: Str_replace(tercari,pencari,subyek)

• StrRev

Digunakan untuk membalik urutan suatu string.

Sintaks: strrev(string)

• StrStr, StriStr dan StrChr

Digunakan untuk mencari keberadaan suatu string di dalam string lain.

Sintaks: strstr(tercari,pencari)

stristr(tercari,pencari)

strchr(tercari,pencari)

• StrToLower

Digunakan untuk merubah suatu string menjadi huruf kecil (lowercase).

Sintaks: strtolower(string)

• StrToUpper

Digunakan untuk merubah suatu string menjadi huruf besar (uppercase)

Sintaks: strtoupper(string)

• SubStr

Digunakan untuk mengambil suatu sub string dengan panjang tertentu dari suatu string pada posisi tertentu pula.

Sintaks: substr(string, int posisi , int posisi)

Contoh :

substr("",0,3); // menghasilkan string "abc"

substr(“abcdefg”,3,2); // menghasilkan string “de”

• SubStr_Count

Digunakan untuk menghitung jumlah sub string dalam suatu string

Sintaks: substr_count( string , string substring)

Contoh :

substr_count("This is a test","is"); //menghasilkan nilai 2

• UCFirst

Digunakan untuk mengganti karakter pertama pada suatu string menjadi huruf besar.

Sintaks: ucfirst(string)

• UCWords

Digunakan untuk mengganti karakter pertama pada setiap kata dalam suatu string menjadi huruf besar.

Sintaks: ucwords(string)

Driver Axioo 7220/M72SR M722SR

User Manual
	M720SR_Manual.pdf	7,046.32 KB 2007-09-28
Integrated Chipset Drivers
WinXP (Ver. r2.04A)	Chipset_XP_R204A.zip	5,555.64 KB 2007-12-14
Integrated Audio Drivers
WinXP (Ver. 5.10.0.5449)	Audio_XP_51005449.zip	25,677.04 KB 2007-12-14
Vista 32 (Ver. 6.0.1.5473)	Audio_VT_6015473.zip	39,312.55 KB 2007-12-15
Integrated Ethernet Controller Drivers
WinXP (Ver. 2.0.1039.1070)	LAN_XP_1070.zip	3,652.79 KB 2007-12-14
Vista 32 (Ver. 2.0.1039.1610)	LAN_VT_1610.zip	3,672.30 KB 2007-12-14
Integrated Modem Drivers
WinXP, Vista 32 (Ver. 6.12.5.0)	Modem_61250.zip	2,742.25 KB 2007-12-14
Integrated Hotkey Drivers
WinXP (Ver. A1.00)	Hotkey_XP_A100.zip	6,726.76 KB 2007-12-14
Vista 32 (Ver. A1.4)	Hotkey_VT_A14.zip	11,881.80 KB 2007-12-14
Integrated Touchpad Drivers
WinXP (Ver. 8.2.18.0)	Touchpad_XP_82180.zip	5,470.00 KB 2007-12-14
Vista 32 (Ver. 9.0.2.0)	Touchpad_VT_9020.zip	11,209.77 KB 2007-12-14
Integrated CardReader Drivers
WinXP, Vista 32 (Ver. 2.00.01)	CR_20001.zip	757.59 KB 2007-12-14
Integrated Wireless LAN Drivers
WinXP (Ver. 5.1234.0719.2006)	WLAN_XP_51234.zip	1,537.69 KB 2007-12-14
Vista 32 (Ver. 6.1285.0215.207)	WLAN_VT_61285.zip	4,892.68 KB 2007-12-14
INtegrated Bluetooth Drivers
WinXP, Vista 32 (5.0.0)	Bluetooth_500.zip	93,822.05 KB 2007-12-14
Integrated VGA Drivers
WinXP (Ver. 6.14.10.3810.zip	SIS_XP_3810.zip	17,980.07 KB 2007-12-14
Vista 32 (Ver. 7.14.10.5070)	SIS_VT_5070.zip	13,742.62 KB 2007-12-14
Integrated PC Camera Drivers
WinXP (Ver. 2.6.0.76L)	CAM_XP_26076L.zip	3,094.48 KB 2007-12-14
Vista 32 (Ver. 6.32.0.2)	CAM_VT32_63202.zip	4,405.83 KB 2007-12-14

Model WINWIN Spiral

The spiral model discussed in Section 2.7.2 suggests a framework activity that addresses customer communication. The objective of this activity is to elicit project requirements from the customer. In an ideal context, the developer simply asks the customer what is required and the customer provides sufficient detail to proceed.
Unfortunately, this rarely happens. In reality, the customer and the developer enter into a process of negotiation, where the customer may be asked to balance functionality, performance, and other product or system characteristics against cost and time to market.
The best negotiations strive for a “win-win” result.7 That is, the customer wins by getting the system or product that satisfies the majority of the customer’s needs and the developer wins by working to realistic and achievable budgets and deadlines.

Boehm’s WINWIN spiral model [BOE98] defines a set of negotiation activities at the beginning of each pass around the spiral. Rather than a single customer communication activity, the following activities are defined:
1. Identification of the system or subsystem’s key “stakeholders.”82. Determination of the stakeholders’ “win conditions.”
3. Negotiation of the stakeholders’ win conditions to reconcile them into a set of win-win conditions for all concerned (including the software project team).
Successful completion of these initial steps achieves a win-win result, which becomes the key criterion for proceeding to software and system definition. The WINWIN spiral model is illustrated in Figure 2.9.
In addition to the emphasis placed on early negotiation, the WINWIN spiral model introduces three process milestones, called anchor points [BOE96], that help establish the completion of one cycle around the spiral and provide decision milestones before the software project proceeds.
In essence, the anchor points represent three different views of progress as the project traverses the spiral. The first anchor point, life cycle objectives (LCO), defines a set of objectives for each major software engineering activity. For example, as part of LCO, a set of objectives establishes the definition of top-level system/product requirements. The second anchor point, life cycle architecture (LCA), establishes objectives that must be met as the system and software architecture is defined. For example, as part of LCA, the software project team must demonstrate that it has evaluated the applicability of off-the-shelf and reusable software components and considered their impact on architectural decisions. Initial operational capability (IOC) is the third anchor point and represents a set of objectives associated with the preparation of the software for installation/distribution, site preparation prior to installation, and assistance required by all parties that will use or support the software.

7 Dozens of books have been written on negotiating skills (e.g., [FIS91], [DON96], [FAR97]). It is one of the more important things that a young (or old) engineer or manager can learn. Read one.

8 A stakeholder is anyone in the organization that has a direct business interest in the system or product to be built and will be rewarded for a successful outcome or criticized if the effort fails.

Software Engineering
A P R A C T I T I O N E R ’ S A P P R O A C H
FIFTH EDITION
Roger S. Pressman, Ph.D.

Model Concurrent Development

The concurrent development model, sometimes called concurrent engineering, has been described in the following manner by Davis and Sitaram [DAV94]:
Project managers who track project status in terms of the major phases [of the classic life cycle] have no idea of the status of their projects. These are examples of trying to track extremely complex sets of activities using overly simple models. Note that although . . . [a large] project is in the coding phase, there are personnel on the project involved in activities typically associated with many phases of development simultaneously. For example, . . . personnel are writing requirements, designing, coding, testing, and integration testing [all at the same time]. Software engineering process models by Humphrey and Kellner [[HUM89], [KEL89]] have shown the concurrency that exists for activities occurring during any one phase. Kellner's more recent work [KEL91] uses statecharts [a notation that represents the states of a process] to represent the concurrent relationship existent among activities associated with a specific event (e.g., a requirements change during late development), but fails to capture the richness of concurrency that exists across all software development and management activities in the project. . . . Most software development process models are driven by time; the later it is, the later in the development process you are. [A concurrent process model] is driven by user needs, management decisions, and review results.

The concurrent process model can be represented schematically as a series of major technical activities, tasks, and their associated states. For example, the engineering activity defined for the spiral model (Section 2.7.2) is accomplished by invoking the following tasks: prototyping and/or analysis modeling, requirements specification, and design.9 Figure 2.10 provides a schematic representation of one activity with the concurrent process model. The activity—analysis—may be in any one of the states10 noted at any given time. Similarly, other activities (e.g., design or customer communication) can be represented in an analogous manner. All activities exist concurrently but reside in different states. For example, early in a project the customer communication activity (not shown in the figure) has completed its first iteration and exists in theawaiting changes state. The analysis activity (which existed in the none state while initial customer communication was completed) now makes a transition into the under development state. If, however, the customer indicates that changes in requirements must be made, the analysis activity moves from the under development state into the awaiting changes state.
The concurrent process model defines a series of events that will trigger transitions from state to state for each of the software engineering activities. For example, during early stages of design, an inconsistency in the analysis model is uncovered.
This generates the event analysis model correction which will trigger the analysis activity from the done state into the awaiting changes state. The concurrent process model is often used as the paradigm for the development of client/server11 applications (Chapter 28). A client/server system is composed of a set of functional components. When applied to client/server, the concurrent process model defines activities in two dimensions [SHE94]: a system dimension and a component dimension. System level issues are addressed using three activities: design, assembly, and use. The component dimension is addressed with two activities: design and realization. Concurrency is achieved in two ways:
(1) system and component activities occur simultaneously and can be modeled using the state-oriented approach described previously; (2) a typical client/server application is implemented with many components, each of which can be designed and realized concurrently.
In reality, the concurrent process model is applicable to all types of software development and provides an accurate picture of the current state of a project. Rather than confining software engineering activities to a sequence of events, it defines a network of activities. Each activity on the network exists simultaneously with other activities.

Events generated within a given activity or at some other place in the activity network trigger transitions among the states of an activity.

9 It should be noted that analysis and design are complex tasks that require substantial discussion.
Parts Three and Four of this book consider these topics in detail.
10 A state is some externally observable mode of behavior.

11 In a client/server applications, software functionality is divided between clients (normally PCs)
and a server (a more powerful computer) that typically maintains a centralized database.

Software Engineering
A P R A C T I T I O N E R ’ S A P P R O A C H
FIFTH EDITION
Roger S. Pressman, Ph.D.

Model Spiral

The spiral model, originally proposed by Boehm [BOE88], is an evolutionary software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model. It provides the potential for rapid development of incremental versions of the software. Using the spiral model, software is developed in a series of incremental releases. During early iterations, the incremental release might be a paper model or prototype. During later iterations, increasingly more complete versions of the engineered system are produced. A spiral model is divided into a number of framework activities, also called task regions.6 Typically, there are between three and six task regions. Figure 2.8 depicts a
spiral model that contains six task regions:
• Customer communication—tasks required to establish effective communication between developer and customer.
• Planning—tasks required to define resources, timelines, and other projectrelated information.
• Risk analysis—tasks required to assess both technical and management risks.
• Engineering—tasks required to build one or more representations of the application.
• Construction and release—tasks required to construct, test, install, and provide user support (e.g., documentation and training).
• Customer evaluation—tasks required to obtain customer feedback based on evaluation of the software representations created during the engineering stage and implemented during the installation stage.
Each of the regions is populated by a set of work tasks, called a task set, that are adapted to the characteristics of the project to be undertaken. For small projects, the number of work tasks and their formality is low. For larger, more critical projects, each task region contains more work tasks that are defined to achieve a higher level of formality. In all cases, the umbrella activities (e.g., software configuration management and software quality assurance) noted in Section 2.2 are applied.
As this evolutionary process begins, the software engineering team moves around the spiral in a clockwise direction, beginning at the center. The first circuit around the spiral might result in the development of a product specification; subsequent passes around the spiral might be used to develop a prototype and then progressively more sophisticated versions of the software. Each pass through the planning region results in adjustments to the project plan. Cost and schedule are adjusted based on feedback derived from customer evaluation. In addition, the project manager adjuststhe planned number of iterations required to complete the software.
Unlike classical process models that end when software is delivered, the spiral model can be adapted to apply throughout the life of the computer software. An alternative view of the spiral model can be considered by examining the project entry point axis, also shown in Figure 2.8. Each cube placed along the axis can be used to represent the starting point for different types of projects. A “concept development project” starts at the core of the spiral and will continue (multiple iterations occur along the spiral path that bounds the central shaded region) until concept development is complete. If the concept is to be developed into an actual product, the process proceeds through the next cube (new product development project entry point) and a “new development project” is initiated. The new product will evolve through a number of iterations around the spiral, following the path that bounds the region that has somewhat lighter shading than the core. In essence, the spiral, when characterized in this way, remains operative until the software is retired. There are times when the process is dormant, but whenever a change is initiated, the process starts at the appropriate entry point (e.g., product enhancement).
The spiral model is a realistic approach to the development of large-scale systems and software. Because software evolves as the process progresses, the developer and customer better understand and react to risks at each evolutionary level. The spiral model uses prototyping as a risk reduction mechanism but, more important, enables the developer to apply the prototyping approach at any stage in the evolution of the product. It maintains the systematic stepwise approach suggested by the classic life cycle but incorporates it into an iterative framework that more realistically reflects the real world. The spiral model demands a direct consideration of technical risks at all stages of the project and, if properly applied, should reduce risks before they become problematic.
But like other paradigms, the spiral model is not a panacea. It may be difficult to convince customers (particularly in contract situations) that the evolutionary approach is controllable. It demands considerable risk assessment expertise and relies on this expertise for success. If a major risk is not uncovered and managed, problems will undoubtedly occur. Finally, the model has not been used as widely as the linear sequential or prototyping paradigms. It will take a number of years before efficacy of this important paradigm can be determined with absolute certainty.


6 The spiral model discussed in this section is a variation on the model proposed by Boehm. For
further information on the original spiral model, see [BOE88]. More recent discussion of Boehm’s
spiral model can be found in [BOE98].

Software Engineering
A P R A C T I T I O N E R ’ S A P P R O A C H
FIFTH EDITION
Roger S. Pressman, Ph.D.

Model Incremental

The incremental model combines elements of the linear sequential model (applied repetitively) with the iterative philosophy of prototyping. Referring to Figure 2.7, the incremental model applies linear sequences in a staggered fashion as calendar time progresses. Each linear sequence produces a deliverable “increment” of the software [MDE93]. For example, word-processing software developed using the incremental paradigm might deliver basic file management, editing, and document production functions in the first increment; more sophisticated editing and document production capabilities in the second increment; spelling and grammar checking in the third increment; and advanced page layout capability in the fourth increment. It should be noted that the process flow for any increment can incorporate the prototyping paradigm.
When an incremental model is used, the first increment is often a core product.
That is, basic requirements are addressed, but many supplementary features (some known, others unknown) remain undelivered. The core product is used by the customer (or undergoes detailed review). As a result of use and/or evaluation, a plan is developed for the next increment. The plan addresses the modification of the core product to better meet the needs of the customer and the delivery of additional features and functionality. This process is repeated following the delivery of each increment, until the complete product is produced.

The incremental process model, like prototyping (Section 2.5) and other evolutionary approaches, is iterative in nature. But unlike prototyping, the incremental model focuses on the delivery of an operational product with each increment. Early increments are stripped down versions of the final product, but they do provide capability that serves the user and also provide a platform for evaluation by the user.
Incremental development is particularly useful when staffing is unavailable for a complete implementation by the business deadline that has been established for the project. Early increments can be implemented with fewer people. If the core product is well received, then additional staff (if required) can be added to implement the next increment. In addition, increments can be planned to manage technical risks. For example, a major system might require the availability of new hardware that is under development and whose delivery date is uncertain. It might be possible to plan early increments in a way that avoids the use of this hardware, thereby enabling partial functionality to be delivered to end-users without inordinate delay.

Software Engineering
A P R A C T I T I O N E R ’ S A P P R O A C H
FIFTH EDITION
Roger S. Pressman, Ph.D.

Model Rapid Aplication Development (RAD)

Rapid application development (RAD) is an incremental software development process model that emphasizes an extremely short development cycle. The RAD model is a “high-speed” adaptation of the linear sequential model in which rapid development is achieved by using component-based construction. If requirements are well understood and project scope is constrained, the RAD process enables a development team to create a “fully functional system” within very short time periods (e.g., 60 to 90 days) [MAR91]. Used primarily for information systems applications, the RAD approach encompasses the following phases [KER94]:
Business modeling. The information flow among business functions is modeled in a way that answers the following questions: What information drives the business process? What information is generated? Who generates it? Where does the information go? Who processes it? Business modeling is described in more detail in Chapter 10.
Data modeling. The information flow defined as part of the business modeling phase is refined into a set of data objects that are needed to support the business. The char-acteristics (called attributes) of each object are identified and the relationships between these objects defined. Data modeling is considered in Chapter 12. Process modeling. The data objects defined in the data modeling phase are transformed to achieve the information flow necessary to implement a business function. Processing descriptions are created for adding, modifying, deleting, or retrieving a data object.
Application generation. RAD assumes the use of fourth generation techniques (Section 2.10). Rather than creating software using conventional third generation programming languages the RAD process works to reuse existing program components (when possible) or create reusable components (when necessary). In all cases, automated tools are used to facilitate construction of the software.
Testing and turnover. Since the RAD process emphasizes reuse, many of the program components have already been tested. This reduces overall testing time. However, new components must be tested and all interfaces must be fully exercised.
The RAD process model is illustrated in Figure 2.6. Obviously, the time constraints imposed on a RAD project demand “scalable scope” [KER94]. If a business application can be modularized in a way that enables each major function to be completed in less than three months (using the approach described previously), it is a candidate for RAD. Each major function can be addressed by a separate RAD team and then integrated to form a whole.
Like all process models, the RAD approach has drawbacks [BUT94]:
• For large but scalable projects, RAD requires sufficient human resources to create the right number of RAD teams.
• RAD requires developers and customers who are committed to the rapid-fire activities necessary to get a system complete in a much abbreviated time frame. If commitment is lacking from either constituency, RAD projects will fail.
• Not all types of applications are appropriate for RAD. If a system cannot be properly modularized, building the components necessary for RAD will be problematic. If high performance is an issue and performance is to be achieved through tuning the interfaces to system components, the RAD approach may not work.
• RAD is not appropriate when technical risks are high. This occurs when a new application makes heavy use of new technology or when the new software requires a high degree of interoperability with existing computer programs.

Software Engineering
A P R A C T I T I O N E R ’ S A P P R O A C H
FIFTH EDITION
Roger S. Pressman, Ph.D.