Site blog

Halaman: () 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 ... 41 ()
Anyone in the world

aaas.JPG

 

Dalam bukunya, Theory U: Leading from the Future as It Emerges, Otto Scharmer memperkenalkan gagasan presencing. Presencing berasal dari gabungan dua kata presence (kehadiran) dan sensing (penginderaan). Presencing ditandai dengan keadaan kesadaran tingkat tinggi yang memungkinkan individu dan organisasi mengubah inner place (sisi dalam) keberadaannya. Ketika perubahan ini terjadi, seseorang atau organisasi mampu menghadirkan ruang masa depan. Esensi kepemimpinan menurut Teori U adalah kemampuan menfasilitasi perubahan sisi dalam seseorang atau organisasi untuk menangkap masa depan dan mengeksplorasi dengan penuh kreativitas.

 

Dalam menggambarkan Teori U, Scharmer meletakkan pondasi bahwa seseorang haruslah berani untuk “menerima” dan “menjawab” situasi tidak hanya dengan cara mengunduh, namun juga melihat sepenuhnya (open mind), mengerti sepenuhnya (open heart), dan menerima sepenuhnya (open will), untuk kemudian mengembangkan keputusan berdasarkan hasil penerimaan itu. Scharmer melihat bahwa konstruksi systems thinkingkonvensional telah berhasil mengajak orang untuk open mind (lewat pemahaman atasevents, patterns, dan structure) dan open heart (lewat pemahaman atas mental model),namun belum sepenuhnya mengeksplorasi bagaimana sumber terdalam di diri kita mampu melihat dan menerima situasi tersebut dengan jernih melalui open will.

Dalam bukunya, Theory U: Leading from the Future as It Emerges, Otto Scharmer memperkenalkan gagasan presencing. Presencing berasal dari gabungan dua kata presence (kehadiran) dan sensing (penginderaan). Presencing ditandai dengan keadaan kesadaran tingkat tinggi yang memungkinkan individu dan organisasi mengubah inner place (sisi dalam) keberadaannya. Ketika perubahan ini terjadi, seseorang atau organisasi mampu menghadirkan ruang masa depan. Esensi kepemimpinan menurut Teori U adalah kemampuan menfasilitasi perubahan sisi dalam seseorang atau organisasi untuk menangkap masa depan dan mengeksplorasi dengan penuh kreativitas.

Dalam menggambarkan Teori U, Scharmer meletakkan pondasi bahwa seseorang haruslah berani untuk “menerima” dan “menjawab” situasi tidak hanya dengan cara mengunduh, namun juga melihat sepenuhnya (open mind), mengerti sepenuhnya (open heart), dan menerima sepenuhnya (open will), untuk kemudian mengembangkan keputusan berdasarkan hasil penerimaan itu. Scharmer melihat bahwa konstruksi systems thinkingkonvensional telah berhasil mengajak orang untuk open mind (lewat pemahaman atasevents, patterns, dan structure) dan open heart (lewat pemahaman atas mental model),namun belum sepenuhnya mengeksplorasi bagaimana sumber terdalam di diri kita mampu melihat dan menerima situasi tersebut dengan jernih melalui open will.

1. Co-initiating (Mulai Bersama): membangun niat umum. Berhenti dan dengarkan orang lain serta panggilan kehidupan apa yang harus Anda lakukan

Pada awal setiap proyek, satu atau beberapa individu kunci berkumpul bersama dengan tujuan membuat perbedaan dalam situasi yang benar-benar penting bagi mereka dan komunitas mereka. Ketika mereka menyatu menjadi sebuah kelompok inti, mereka mempertahankan niat umum berkaitan dengan tujuan mereka, orang-orang yang ingin dilibatkan, dan proses yang ingin mereka gunakan. Konteks yang memungkinkan kelompok inti semacam ini untuk terbentuk adalah proses mendengarkan yang dalam - mendengarkan apa panggilan hidup yang harus Anda dan yang lain lakukan.

2. Co-sensing (Merasakan Bersama): mengamati, mengamati, mengamati. Pergi ke tempat yang paling potensial dan dengarkan dengan pikiran dan hati yang terbuka lebar

Faktor pembatas perubahan transformasional bukanlah kurangnya visi atau gagasan, tetapi ketidakmampuan untuk merasakan - yaitu, untuk melihat secara mendalam, tajam, dan secara kolektif. Ketika anggota kelompok melihat bersama-sama dengan kedalaman dan kejelasan, mereka menjadi sadar akan potensi kolektif mereka - hampir seolah organ kolektif baru dari pengelihatan dibuka. Goethe menjelaskannya: "Setiap objek, dengan maksud baik, membuka organ penglihatan baru dalam diri kita".

Ilmuwan kognitif Francisco Varela pernah mengatakan kepada saya tentang sebuah eksperimen yang telah dilakukan dengan anak-anak kucing baru lahir, yang matanya belum terbuka. Mereka ditempatkan bersama dalam berpasangan, dengan satu di belakang yang lain sedemikian rupa sehingga hanya kucing yang lebih rendah yang mampu bergerak. Kedua anak kucing mengalami gerakan spasial yang sama, tapi semua kerja keras itu dilakukan oleh kucing yang lebih rendah. Hasil dari percobaan ini adalah bahwa kucing yang lebih rendah belajar melihat cukup normal, sedangkan kucing yang di atas tidak - kapasitasnya untuk melihat berkembang tidak memadai dan lebih lambat. Percobaan ini menggambarkan bahwa kemampuan untuk melihat dikembangkan dengan aktivitas seluruh organisme.

Dalam mengorganisasi pengetahuan manajemen, strategi, inovasi, dan pembelajaran, kita seperti kucing yang di atas - kita bergantung pada kerja keras para ahli, konsultan, dan guru untuk memberitahu kita bagaimana dunia bekerja. Untuk masalah sederhana, ini mungkin merupakan pendekatan yang tepat. Tetapi jika Anda berada dalam bisnis inovasi, maka cara kucing yang di atas tidak akan berfungsi. Hal terakhir yang tiap inovator sejati akan gantungkan adalah persepsi. Ketika berinovasi, kita harus pergi sendiri, bicara dengan orang, dan tetap berhubungan dengan isu sambil mereka berkembang. Tanpa hubungan langsung pada konteks situasi, kita tidak dapat belajar melihat dan bertindak secara efektif.

Apa yang hilang dalam organisasi saat ini dan masyarakat kita adalah seperangkat praktek yang memungkinkan penglihatan secara mendalam semacam ini - penginderaan - terjadi secara kolektif dan melintasi batas-batas. Ketika penginderaan terjadi, kelompok sebagai kesatuan dapat melihat peluang yang muncul dan kekuatan kunci sistemik dalam isu.

3. Presencing: terhubung ke sumber inspirasi dan kehendak bersama. Pergi ke tempat keheningan dan biarkan pengetahuan dalam muncul

Di bagian bawah U, individu atau kelompok dalam perjalanan U datang ke ambang yang membutuhkan "melepaskan" segala sesuatu yang tidak penting. Dalam banyak hal, batas ini seperti gerbang di Yerusalem kuno yang disebut "The Needle", yang begitu sempit sehingga ketika unta dengan banyak bawaan mencapai itu, pengemudi unta harus melepaskan semua barang bawaan itu agar unta dapat lewat - Sesuai Perjanjian Baru yang mengatakan bahwa "Lebih mudah bagi seekor unta masuk melalui lubang jarum daripada seorang kaya memasuki kerajaan Allah".

Pada saat yang sama, kita tanggalkan aspek diri yang tidak penting (melepaskan), kita juga membuka diri untuk aspek baru dari masa depan diri tertinggi kita (membiarkan datang). Inti dari presencing adalah pengalaman kedatangan hal baru dan perubahan hal yang lama. Setelah grup melintasi batas ini, tidak ada yang tetap sama. Anggota individu dan kelompok sebagai keseluruhan mulai beroperasi dengan tingkat energi tinggi dan rasa kemungkinan masa depan. Seringkali mereka kemudian mulai berfungsi sebagai kendaraan yang disengaja untuk masa depan yang mereka rasa ingin muncul.

4. Co-creating (Mencipta Bersama): membentuk dasar (prototype) hal baru dalam contoh nyata untuk mengeksplor masa depan dengan bertindak

Saya sering bekerja dengan orang-orang yang terlatih seperti insinyur, ilmuwan, manajer, dan ekonom (seperti saya). Tapi ketika datang ke inovasi, kita semua telah menerima pendidikan yang salah. Dalam semua pelatihan dan pendidikan, satu ketrampilan penting hilang: seni dan praktek membentuk dasar. Itulah apa yang Anda pelajari ketika Anda menjadi seorang desainer. Apa yang dipelajari desainer adalah kebalikan dari apa yang disosialisasikan dan bisasakan untuk kita lakukan.

Saya masih ingat kunjungan pertama saya ke sebuah sekolah seni dan desain ketika saya adalah seorang mahasiswa doktoral di Jerman. Karena saya telah menerbitkan sebuah buku tentang estetika dan manajemen, seorang profesor desain di Berlin Academy of Arts, Nick Roericht, mengundang saya untuk mengajar bersamanya dalam sebuah lokakarya. Malam sebelum lokakarya, saya diundang untuk bertemu dengan Roericht dan lingkaran kelompoknya di loteng apartemennya. Saya sangat ingin bertemu kelompok itu dan melihat bagaimana desainer terkenal menata loteng apartemen Berlinnya. Saat saya datang, saya terkejut. Loteng itu luas, indah - tapi hampir kosong. Di sudut dapur yang sangat kecil berdiri sebuah wastafel, mesin espresso, beberapa cangkir, dan meja dapur kuasi. Tapi tidak ada lemari. Tidak ada mesin cuci. Tidak ada meja di ruang utama. Tidak ada kursi. Tidak ada sofa. Tidak ada kecuali beberapa bantal untuk duduk.

Kami memiliki malam yang hebat, dan kemudian saya mengetahui bahwa loteng kosong itu merefleksikan pendekatannya akan membangun dasar. Misalnya, ketika ia mengembangkan desain prototipe interior untuk kantor dekan di sekolah, dia mengeluarkan semua perabotan dan kemudian melihat apa yang terjadi di sana. Roericht dan murid-muridnya kemudian melengkapinya sesuai kebutuhan kepala sekolah yang sebenarnya - pertemuan yang dilakukannya dan semacamnya - menyediakan objek dan perabotan yang dibutuhkan dalam kenyataan. Membangun dasar menuntut bahwa pertama-tama Anda harus mengosongkan semua benda (melepaskan). Kemudian Anda menentukan apa yang benar-benar butuhkan (biarkan datang) dan menyediakan solusi prototipe untuk kebutuhan nyata. Anda mengamati dan beradaptasi berdasarkan apa yang terjadi selanjutnya.

Ini adalah pelajaran yang berharga bagi saya. Saya berpikir: Nak, jika profesor desain terkenal ini memiliki loteng tanpa apa-apa di dalamnya, kenapa sekolah-sekolah manajemen terbaik dan semua pemikir manajemen terkenal tidak bisa membuat desain organisasi yang sama-sama simpel yang membuang semua birokrasi yang tidak berfungsi?

Keesokan harinya kami mulai lokakarya sekitar pukul 1. Tugasnya adalah menciptakan papan permainan untuk semua cara yang ada dan alternatif dalam mengatur ekonomi lokal dan global. Sebuah tantangan desain yang cukup ambisius, pikirku. Tapi apa yang dikatakan Roericht berikutnya benar-benar mengagetkanku: "Oke, sekarang bagi menjadi beberapa kelompok. Jam 5 tiap kelompok mempresentasikan prototipe pertamanya". Saya tercengang. Di dunia ekonomi dan manajemenku, reaksi untuk tugas desain seperti ini seharusnya: "Pertama, itu terlalu besar. Anda harus mempersempit pertanyaannya. Dua, jika kamu melakukannya, butuh waktu setahun atau lebih untuk meninjau semua pekerjaan yang harus dilakukan mengenai topik itu. Lalu muncul dengan kesimpulan dan mungkin masukan untuk apa yang dilakukan selanjutnya". Tapi maju dengan prototipe dalam waktu empat jam? Pelatihan profesional saya bersikeras bahwa pendekatan ini kurang mendalam dan kurang dari segi metode. Tapi yang tidak saya sadar sebelumnya adalah maju dengan prototype kurang dari empat jam adalah metodenya. Saat metode konvensional berdasarkan pada penetrasi analitis, lalu buat desain cetak biru, lalu membangunnya, metode prototipe bekerja dengan berbeda. Pertama memperjelas pertanyaannya, kemudian amati, lalu bangun agar lebih dapat mengamati, lalu beradaptasi dan sebagainya.

Jadi, prototipe bukanlah tahap yang datang setelah analisis. Prototipe adalah bagian dari proses penginderaan dan penemuan di mana kita mengeksplorasi masa depan dengan bertindak bukan dengan berpikir dan merefleksikan. Ini adalah seperti titik sederhana - tapi saya telah menemukan bahwa proses inovasi dari banyak organisasi berhenti di sana, di metode analisis lama tentang "kelumpuhan analisis".

Gerakan co-creation dari perjalanan U menghasilkan satu set contoh kehidupan kecil yang mengeksplorasi masa depan dengan bertindak. Ini juga menghasilkan jaringan pencipta perubahan yang bersemangat dan dengan cepat berkembang yang meningkatkan pembelajaran mereka di seluruh prototipe dan yang saling membantu dalam menghadapi tantangan inovasi apapun yang mereka hadapi.

5. Co-evolving (Berkembang Bersama): mewujudkan hal baru dalam ekosistem yang memfasilitasi penglihatan dan tindakan dari keseluruhan

Setelah kita mengembangkan beberapa prototipe dan mikrokosmos yang baru, langkah selanjutnya adalah meninjau apa yang telah dipelajari - apa yang bekerja dan tidak - dan kemudian menentukan prototipe mana yang memiliki dampak tertinggi pada sistem atau situasi yang ada. Datang dengan penilaian suara pada tahap ini seringkali memerlukan keterlibatan pemangku kepentingan dari lembaga dan sektor lain. Seringkali, apa yang Anda pikir akan Anda buat di awal proses U berbeda dari apa yang akhirnya muncul.

Hasil gerakan co-evolving di ekosistem inovasi yang menghubungkan inisiatif prototipe tinggi dengan institusi dan pelaku yang dapat membantu membawa ke tingkat berikutnya dalam uji coba dan penilaian.

Lima gerakan U berlaku baik di tingkat makro dari proyek inovasi dan arsitektur perubahan serta tingkat meso dan mikro dari kelompok percakapan atau interaksi satu lawan satu. Dalam seni bela diri Anda pergi melalui U dalam sepersekian detik. Ketika diterapkan untuk proyek-proyek inovasi besar, proses U terbentang selama periode yang lebih lama dan dalam bentuk yang berbeda. Jadi, komposisi tim di proyek-proyek seperti biasanya berubah dan beradaptasi untuk beberapa tingkat setelah setiap gerakan.

Associated Kursus: RE141668RE141668
[ Mengubah: Thursday, 12 October 2017, 20:49 ]
 
Gambar dari REWINDA 2216105064
by REWINDA 2216105064 - Saturday, 7 October 2017, 04:13
Anyone in the world

kisah-sebatang-pensil.jpg

Si anak lelaki memandangi neneknya yang sedang menulis surat, lalu bertanya, “Apakah Nenek sedang menulis cerita tentang kegiatan kita? Apakah cerita ini tentang aku?”

Sang nenek berhenti menulis surat dan berkata kepada cucunya, “Nenek memang sedang menulis tentang dirimu, sebenarnya, tetapi ada yang lebih penting daripada kata – kata yang sedang Nenek tulis, yakni pensil yang Nenek gunakan. Mudah – mudahan kau menjadi seperti pensil ini, kalau kau sudah dewasa nanti.”

Si anak lelaki merasa heran, diamatinya pensil itu, kelihatannya biasa saja.

“Tapi pensil itu sama saja dengan pensil – pensil lain yang pernah kulihat!”

“Itu tergantung bagaimana kau memandang segala sesuatunya. Ada lima pokok yang penting, dan kalau kau berhasil menerapkannya, kau akan senantiasa merasa damai dalam menjalani hidupmu.”

Pertama : Kau sanggup melakukan hal – hal yang besar, tetapi jangan pernah lupa bahwa ada tangan yang membimbing setiap langkahmu. Kita menyebutnya tangan Tuhan. Dia selalu membimbing kita sesuai dengan kehendak-Nya.

Kedua : Sesekali Nenek mesti berhenti menulis dan meraut pensil ini. Pensil ini akan merasa sakit sedikit, tetapi sesudahnya dia menjadi jauh lebih tajam. Begitu pula denganmu, kau harus belajar menanggung beberapa penderitaan dan kesedihan, sebab penderitaan dan kesedihan akan menjadikanmu orang yang lebih baik.

Ketiga : Pensil ini tidak keberatan kalau kita menggunakan penghapus untuk menghapus kesalahan – kesalahan yang kita buat. Ini berarti, tidak apa – apa kalau kita memperbaiki sesuatu yang pernah kita lakukan. Kita jadi tetap berada di jalan yang benar untuk menuju keadilan.

Keempat : Yang paling penting pada sebatang pensil bukanlah bagian luarnya yang dari kayu, melainkan bahan grafit di dalamnya. Jadi, perhatikan selalu apa yang sedang berlangsung di dalam dirimu.

Dan yang Kelima : Pensil ini selalu meninggalkan bekas. Begitu pula apa yang kau lakukan. Kau harus tahu bahwa segala sesuatu yang kau lakukan dalam hidupmu akan meninggalkan bekas, maka berusahalah untuk menyadari hal tersebut dalam setiap tindakanmu.

Associated Kursus: RE141668RE141668
[ Mengubah: Sunday, 15 October 2017, 10:43 ]
 
Anyone in the world

1%20Iq7fJbC3AOowdL9iOoivvQ.png

 

Terkadang, ide dapat muncul secara tiba-tiba tanpa bersusah payah mencarinya. Bahkan orang kreatif akan dengan mudah menemukan ide ketika dihadapkan dalam berbagai masalah. Seringkali ide kreatif tersebut terinspirasi dari hal-hal dan situasi yang tidak terduga. Namun bagi sebagian orang menemukan ide kreatif bukanlah hal yang mudah. Oleh karena itu, diperlukan adanya teknik dalam berpikir kreatif.

 

Salah satu teknik berpikir kreatif yang telah ada disebut Silly Cow. Metode ini umumnya digunakan untuk menumbuhkan ide dalam berbisnis. Namun cara ni juga dapat diterapkan dalam berbagai persoalan lain yang membutuhkan kreativitas. Metode berpikir ini dapat dilakukan sendiri maupun dengan forum group discussion. Terdapat dua cara untuk menerapkan metode Silly Cow. Pertama, cara yang dapat Anda lakukan sendiri. Langkah awal yang harus Anda lakukan, coba pikirkan tentang sapi. Apa saja yang Anda ketahui tentang sapi? Misalkan : hitam-putih, daging, susu, berkaki empat, kotoran, daging glonggongan, suap kasus impor daging dan hal-hal lain yang langsung terpikirkan oleh Anda. Kemudian lanjutkan dengan pertanyaan “Apa yang berhubungan dengan hitam-putih?” “Apa yang berhubungan dengan daging?” dan seterusnya dan seterusnya. Teruskan hingga Anda mendapatkan banyak ide, kemudian pilihlah ide yang paling sesuai dengan permasalahan Anda.  

 

Cara yang kedua sebaiknya dilakukan berkelompok atau dengan forum group discussion. Cara ini lebih efisien dan efektif untuk memicu keluarnya ide-ide kreatif yang Anda miliki. Metode ini dapat diterapkan dengan sebuah game yang menyenangkan. Pertama, masing-masing partisipan menyebutkan tiga kata/hal yang berhubungan dengan sapi.  Dari seluruh kata yang terkumpul, instruktur memberikan 3 kata secara acak kepada masing-masing partisipan. Kemudian masing-masing orang dapat mengajukan sebuah ide dengan tiga kata yang telah dipilihkan. Metode ini memiliki tujuan utama untuk menjadikan peserta lebih inovatif dan berpikir ‘out of the box’. Kuncinya adalah spontanitas peserta ketika menyebutkan tiga kata. Setiap ide yang muncul, tidak peduli betapa konyol dan sangat tidak masuk akal, patut untuk diharga. Metode ini dapat dikembangkan dengan pemilihan tema selain sapi.

Selamat mencoba!!

 

Sumber :

http://adinhumanomics.tumblr.com/post/68169384859/idea-silly-cow-lotus-blossom-and-consumer

https://www.linkedin.com/pulse/silly-cow-instartups-anestis-tsoukalis

 

Associated Kursus: RE141668RE141668
[ Mengubah: Monday, 27 February 2017, 22:41 ]
 
Anyone in the world

 

Metode ini dilakukan dengan membangun ide-ide baru dari masalah yang ada. Berikut adalah langkah-langkah melakukan teknik lotus blossom.

  1. Letakan permasalahan utama kotak pusat.
  2. Buat ide-ide yang menyangkut permasalahan utama menggunakan ‘kelompak-kelopak’ di sekitar kotak permasalan utam.
  3. Ide-ide baru tersebut akan memacu ide-ide baru yang lain. Sehingga seakan-akan ide dari poin (2) menjadi ide pusat yang baru.
  4. Usahakan untuk membuat delapan ide baru menyangkut poin (3).
  5. Terakhir, bandingkan tiap ide yang ada dengan keadaan permasalahan yang dihadapi dan untung-rugi yang akan diperoleh pada tiap-tiap ide.

 

LotusFlower_1.jpg 

Gambar 1. Tabel sketsa lotus blossom.

 tumblr_inline_mwvnqd2WZ41sojwud.png

Gambar 2. Sketsa metode lotus blossom.

Bila pengembangan ide kreatif menggunakan metode ini sudah selesai, maka gambar sketsa idenya akan seperti gambar 2 di atas.

 

Sumber :

http://5by5design.com/advice/lotus-blossom-technique

http://members.optusnet.com.au/charles57/Creative/Techniques/lotus.htm

http://www.speech-topics-help.net/speaking-research-methods.html

Associated Kursus: RE141668RE141668
 
Anyone in the world

The software process is represented schematically in Figure 1. Referring to the figure, each framework activity is populated by a set of software engineering actions. Each software engineering action is defined by a task set that identifies the work tasks that are to be completed, the work products that will be produced, the quality assurance points that will be required, and the milestones that will be used to indicate progress.

 

Software%20Process.JPG

 Figure 1 

 

A generic process framework for software engineering defines five framework activities communication, planning, modeling, construction, and deployment. In addition, a set of umbrella activities-project tracking and control, risk management, quality assurance, configuration management, technical reviews, and others-are applied throughout the process. You should note that one important aspect of the software process has not yet been discussed. This aspect-called process flow-describes how the framework activities and the actions and tasks that occur within each framework activity are organized with respect to sequence and time and is illustrated in Figure 2.

A linear process flow executes each of the five framework activities in sequence, beginning with communication and culminating with deployment (Figure 2 a). An iterative process flow repeats one or more of the activities before proceeding to the next (Figure 2 b). An evolutionary process flow executes the activities in a “circular” manner. Each circuit through the five activities leads to a more complete version of the software (Figure 2 c). A parallel process flow (Figure 2 d) executes one or more activities in parallel with other activities (modeling for one aspect of the software might be executed in parallel with construction of another aspect of the software).

 

Defining a Framework Activity

Although I have described five framework activities and provided a basic definition of each software team would need significantly more information before it could properly execute any one of these activities as part of the software process. Therefore, you are faced with a key question : What actions are appropriate for a framework activity, given the nature of the problem to be solved, the characteristics of the people doing the work, and the stakeholders who are sponsoring the project?

 

Process%20Flow.JPG

 Figure 2

 

For a small software project requested by one person (at a remote location) with simple, straightforward requirements, the communication activity might encompass little more than a phone call with the appropriate stakeholder. Therefore, the only necessary action is phone conversation, and the work tasks (the task set) that this action encompasses are :

  1. Make contact with stakeholder via telephone.
  2. Discuss requirements and take notes.
  3. Organize notes into a brief written statement of requirements.
  4. E-mail to stakeholder for review and approval.

If the project was considerably more complex with many stakeholders, each with a different set of sometime conflicting) requirements, the communication activity might have six distinct actions (described in Chapter 5): inception, elicitation, elaboration, negotiation, pecification, and validation. Each of these software engineering actions would have many work tasks and a number of distinct work products.

 

Identifying a Task Set

Referring again to Figure 1, each software engineering action (elicitation, an action associated with the communication activity) can be represented by a number of different task sets-each a collection of software engineering work tasks, related work products, quality assurance points, and project milestones. You should choose a task set that best accommodates the needs of the project and the characteristics of your team. This implies that a software engineering action can be adapted to the specific needs of the software project and the characteristics of the project team.

 

File%201.JPG

 Figure 3

Associated Kursus: KI142303BKI142303B
[ Mengubah: Saturday, 7 January 2017, 10:26 ]
 
Anyone in the world

Systems Engineering

Systems engineering encompasses all of the activities involved in procuring, specifying, designing, implementing, validating, deploying, operating, and maintaining sociotechnical systems. Systems engineers are not just concerned with software but also with hardware and the system’s interactions with users and its environment. They must think about the services that the system provides, the constraints under which the system must be built and operated, and the ways in which the system is used to fulfill its purpose or purposes.

There are three overlapping stages (Figure 1) in the lifetime of large and complex sociotechnical systems :

  1. Procurement or acquisition During this stage, the purpose of a system is decided; high-level system requirements are established; decisions are made on how functionality will be distributed across hardware, software, and people, and the components that will make up the system are purchased.
  2. Development During this stage, the system is developed. Development processes include all of the activities involved in system development such as requirements definition, system design, hardware and software engineering, system integration, and testing. Operational processes are defined and the training courses for system users are designed.
  3. Operation At this stage, the system is deployed, users are trained, and the system is brought into use. The planned operational processes usually then have to change to reflect the real working environment where the system is used. Over time, the system evolves as new requirements are identified. Eventually, the system declines in value and it is decommissioned and replaced.

 

11A.JPG

Figure 1

 

These stages are not independent. Once the system is operational, new equipment and software may have to be procured to replace obsolete system components, to provide new functionality, or to cope with increased demand. Similarly, requests for changes during operation require further system development.

The overall security and dependability of a system is influenced by activities at all of these stages. Design options may be restricted by procurement decisions on the scope of the system and on its hardware and software. It may be impossible to implement some kinds of system safeguards. They may introduce vulnerabilities that could lead to future system failures.

Human errors made during the specification, design, and development stages may mean that faults are introduced into the system. Inadequate testing may mean that faults are not discovered before a system is deployed. During operation, errors in configuring the system for deployment may lead to further vulnerabilities. System operators may make mistakes in using the system. Assumptions made during the original procurement may be forgotten when system changes are made and, again, vulnerabilities can be introduced into the system.

An important difference between systems and software engineering is the involvement of a range of professional disciplines throughout the lifetime of the system. For example, the technical disciplines that may be involved in the procurement and development of a new system for air traffic management are shown in Figure 2. Architects and civil engineers are involved because new air traffic management systems usually have to be installed in a new building. Electrical and mechanical engineers are involved to specify and maintain the power and air conditioning. Electronic engineers are concerned with computers, radars, and other equipment. Ergonomists design the controller workstations and software engineers and user interface designers are responsible for the software in the system.

 

11B.JPG

Figure 2

 

The involvement of a range of professional disciplines is essential because there are so many different aspects of complex sociotechnical systems. However, differences between disciplines can introduce vulnerabilities into systems and so compromise the security and dependability of the system being developed :

  1. Different disciplines use the same words to mean different things. Misunderstandings are common in discussions between engineers from different backgrounds. If these are not discovered and resolved during system development, they can lead to errors in delivered systems. For example, an electronic engineer who may know a little bit about C# programming may not understand that a method in Java is comparable to a function in C.
  2. Each discipline makes assumptions about what can or can’t be done by other disciplines. These are often based on an inadequate understanding of what is actually possible. For example, a user interface designer may propose a graphical UI for an embedded system that requires a great deal of processing and so overloads the processor in the system.
  3. Disciplines try to protect their professional boundaries and may argue for certain design decisions because these decisions will call for their professional expertise. Therefore, a software engineer may argue for a software-based door locking system in a building, although a mechanical, key-based system may be more reliable.

 

System Procurement

The initial phase of systems engineering is system procurement (sometimes called system acquisition). At this stage, decisions are made on the scope of a system that is to be purchased, system budgets and timescales, and the high-level system requirements. Using this information, further decisions are then made on whether to procure a system, the type of system required, and the supplier or suppliers of the system. The drivers for these decisions are :

  1. The state of other organizational systems If the organization has a mixture of systems that cannot easily communicate or that are expensive to maintain, then procuring a replacement system may lead to significant business benefits.
  2. The need to comply with external regulations Increasingly, businesses are regulated and have to demonstrate compliance with externally defined regulations (e.g., Sarbanes-Oxley accounting regulations in the United States). This may require the replacement of noncompliant systems or the provision of new systems specifically to monitor compliance.
  3. External competition If a business needs to compete more effectively or maintain a competitive position, investment in new systems that improve the efficiency of business processes may be advisable. For military systems, the need to improve capability in the face of new threats is an important reason for procuring new systems.
  4. Business reorganization Businesses and other organizations frequently restructure with the intention of improving efficiency and/or customer service. Reorganizations lead to changes in business processes that require new systems support.
  5. Available budget The budget available is an obvious factor in determining the scope of new systems that can be procured.

 

11C.JPG

Figure 3

 

In addition, new government systems are often procured to reflect political changes and political policies. For example, politicians may decide to buy new surveillance systems, which they claim will counter terrorism. Buying such systems shows voters that they are taking action. However, such systems are often procured without a cost-benefit analysis, where the benefits that result from different spending options are compared.

Large, complex systems usually consist of a mixture of off-the-shelf and specially built components. One reason why more and more software is included in systems is that it allows more use of existing hardware components, with the software acting as ‘glue’ to make these hardware components work together effectively. The need to develop this ‘glueware’ is one reason why the savings from using off-the-shelf components are sometimes not as great as anticipated.

Figure 3 shows a simplified model of the procurement process for both COTS system components and system components that have to be specially designed and developed. Important points about the process shown in this diagram are :

  1. Off-the-shelf components do not usually match requirements exactly, unless the requirements have been written with these components in mind. Therefore, choosing a system means that you have to find the closest match between the system requirements and the facilities offered by off-the-shelf systems. You may then have to modify the requirements. This can have knock-on effects on other subsystems.
  2. When a system is to be built specially, the specification of requirements is part of the contract for the system being acquired. It is therefore a legal as well as a technical document.
  3. After a contractor has been selected, to build a system, there is a contract negotiation period where you may have to negotiate further changes to the requirements and discuss issues such as the cost of changes to the system. Similarly, once a COTS system has been selected, you may negotiate with the supplier on costs, licence conditions, possible changes to the system, etc.

The software and hardware in sociotechnical systems are usually developed by a different organization (the supplier) from the organization that is procuring the overall sociotechnical system. The reason for this is that the customer’s business is rarely software development so its employees do not have the skills needed to develop the systems themselves. In fact, very few companies have the capabilities to design, manufacture, and test all the components of a large, complex sociotechnical system.

 

11D.JPG

Figure 4

 

Consequently, the system supplier, who is usually called the principal contractor, often contracts out the development of different subsystems to a number of subcontractors. For large systems, such as air traffic control systems, a group of suppliers may form a consortium to bid for the contract. The consortium should include all of the capabilities required for this type of system. This includes computer hardware suppliers, software developers, peripheral suppliers, and suppliers of specialist equipment such as radar systems.

The procurer deals with the contractor rather than the subcontractors so that there is a single procurer/supplier interface. The subcontractors design and build parts of the system to a specification that is produced by the principal contractor. Once completed, the principal contractor integrates these different components and delivers them to the customer. Depending on the contract, the procurer may allow the principal contractor a free choice of subcontractors or may require the principal contractor to choose subcontractors from an approved list.

Decisions and choices made during system procurement have a profound effect on the security and dependability of a system. For example, if a decision is made to procure an off-the-shelf system, then the organization has to accept that they have very limited influence over the security and dependability requirements of this system. These largely depend on decisions made by system vendors. In addition, off-theshelf systems may have known security weaknesses or require complex configuration. Configuration errors, where entry points to the system are not properly secured, are a major source of security problems.

On the other hand, a decision to procure a custom system means that significant effort must be devoted to understanding and defining security and dependability requirements. If a company has limited experience in this area, this is quite a difficult thing to do. If the required level of dependability as well as acceptable system performance is to be achieved, then the development time may have to be extended and the budget increased.

Associated Kursus: KI142303BKI142303B
[ Mengubah: Saturday, 7 January 2017, 10:23 ]
 
Anyone in the world

Hazard Analysis

Hazard analysis is the process of discovering the root causes of hazards in a safetycritical system. Your aim is to find out what events or combination of events could cause a system failure that results in a hazard. To do this, you can use either a topdown or a bottom-up approach. Deductive, top-down techniques, which tend to be easier to use, start with the hazard and work up from that to the possible system failure. Inductive, bottom-up techniques start with a proposed system failure and identify what hazards might result from that failure.

Various techniques have been proposed as possible approaches to hazard decomposition or analysis. These are summarized by Storey (1996). They include reviews and checklists, formal techniques such as Petri net analysis (Peterson, 1981), formal logic (Jahanian and Mok, 1986), and fault tree analysis (Leveson and Stolzy, 1987, Storey, 1996). As I don’t have space to cover all of these techniques here, I focus on a widely used approach to hazard analysis based on fault trees. This technique is fairly easy to understand without specialist domain knowledge.

To do a fault tree analysis, you start with the hazards that have been identified. For each hazard, you then work backwards to discover the possible causes of that hazard. You put the hazard at the root of the tree and identify the system states that can lead to that hazard. For each of these states, you then identify further system states that can lead to them. You continue this decomposition until you reach the root cause(s) of the risk. Hazards that can only arise from a combination of root causes are usually less likely to lead to an accident than hazards with a single root cause.

Figure 1 is a fault tree for the software-related hazards in the insulin delivery system that could lead to an incorrect dose of insulin being delivered. In this case, I have merged insulin underdose and insulin overdose into a single hazard, namely ‘incorrect insulin dose administered.’ This reduces the number of fault trees that are required. Of course, when you specify how the software should react to this hazard, you have to distinguish between an insulin underdose and an insulin overdose. As I have said, they are not equally serious—in the short term, an overdose is the more serious hazard.

 

10A.JPG

Figure 1

 

From Figure 1, you can see that :

  1. There are three conditions that could lead to the administration of an incorrect dose of insulin. The level of blood sugar may have been incorrectly measured so the insulin requirement has been computed with an incorrect input. The delivery system may not respond correctly to commands specifying the amount of insulin to be injected. Alternatively, the dose may be correctly computed but it is delivered too early or too late.
  2. The left branch of the fault tree, concerned with incorrect measurement of the blood sugar level, looks at how this might happen. This could occur either because the sensor that provides an input to calculate the sugar level has failed or because the calculation of the blood sugar level has been carried out incorrectly. The sugar level is calculated from some measured parameter, such as the conductivity of the skin. Incorrect computation can result from either an incorrect algorithm or an arithmetic error that results from the use of floating point numbers.
  3. The central branch of the tree is concerned with timing problems and concludes that these can only result from system timer failure.
  4. The right branch of the tree, concerned with delivery system failure, examines possible causes of this failure. These could result from an incorrect computation of the insulin requirement, or from a failure to send the correct signals to the pump that delivers the insulin. Again, an incorrect computation can result from algorithm failure or arithmetic errors.

Fault trees are also used to identify potential hardware problems. Hardware fault trees may provide insights into requirements for software to detect and, perhaps, correct these problems. For example, insulin doses are not administered at a very high frequency, no more than two or three times per hour and sometimes less often than this. Therefore, processor capacity is available to run diagnostic and self-checking programs. Hardware errors such as sensor, pump, or timer errors can be discovered and warnings issued before they have a serious effect on the patient.

 

Risk Reduction

Once potential risks and their root causes have been identified, you are then able to derive safety requirements that manage the risks and ensure that incidents or accidents do not occur. There are three possible strategies that you can use :

  1. Hazard avoidance The system is designed so that the hazard cannot occur.
  2. Hazard detection and removal The system is designed so that hazards are detected and neutralized before they result in an accident.
  3. Damage limitation The system is designed so that the consequences of an accident are minimized.

Normally, designers of critical systems use a combination of these approaches. In a safety critical system, intolerable hazards may be handled by minimizing their probability and adding a protection system that provides a safety backup. For example, in a chemical plant control system, the system will attempt to detect and avoid excess pressure in the reactor. However, there may also be an independent protection system that monitors the pressure and opens a relief valve if high pressure is detected.

 

10B.JPG

Figure 2

 

In the insulin delivery system, a ‘safe state’ is a shutdown state where no insulin is injected. Over a short period this is not a threat to the diabetic’s health. For the software failures that could lead to an incorrect dose of insulin are considered, the following ‘solutions’ might be developed :

  1. Arithmetic error This may occur when an arithmetic computation causes a representation failure. The specification should identify all possible arithmetic errors that may occur and state that an exception handler must be included for each possible error. The specification should set out the action to be taken for each of these errors. The default safe action is to shut down the delivery system and activate a warning alarm.
  2. Algorithmic error This is a more difficult situation as there is no clear program exception that must be handled. This type of error could be detected by comparing the required insulin dose computed with the previously delivered dose. If it is much higher, this may mean that the amount has been computed incorrectly. The system may also keep track of the dose sequence. After a number of above-average doses have been delivered, a warning may be issued and further dosage limited.

Some of the resulting safety requirements for the insulin pump software are shown in Figure 2. These are user requirements and, naturally, they would be expressed in more detail in the system requirements specification. In Figure 2, the references to Tables 3 and 4 relate to tables that are included in the requirements document they are not shown here.

Associated Kursus: KI142303BKI142303B
 
Anyone in the world

Architectural Patterns

Architectural patterns, are abstract, stylized descriptions of good design practice. They encapsulate knowledge about the organization of system architectures, when these architectures should be used and their advantages and disadvantages. You should not, however, think of an architectural pattern as a generic design to be instantiated. Rather, you use the pattern to understand an architecture and as starting point for creating your own specific architectural design.

As you might expect, the differences between embedded and interactive software means that different architectural patterns are used for embedded systems, rather than the architectural patterns discussed in Chapter 6. Embedded systems’ patterns are process-oriented rather than object- or component-oriented. In this section, I discuss three real-time architectural patterns that are commonly used :

  1. Observe and React This pattern is used when a set of sensors are routinely monitored and displayed. When the sensors show that some event has occurred (e.g., an incoming call on a cell phone), the system reacts by initiating a process to handle that event.
  2. Environmental Control This pattern is used when a system includes sensors, which provide information about the environment and actuators that can change the environment. In response to environmental changes detected by the sensor, control signals are sent to the system actuators.
  3. Process Pipeline This pattern is used when data has to be transformed from one representation to another before it can be processed. The transformation is implemented as a sequence of processing steps, which may be carried out concurrently. This allows for very fast data processing, because a separate core or processor can execute each transformation.

 

9A.JPG

Figure 1

 

These patterns can of course be combined and you will often see more than one of them in a single system. For example, when the Environmental Control pattern is used, it is very common for the actuators to be monitored using the Observe and React pattern. In the event of an actuator failure, the system may react by displaying a warning message, shutting down the actuator, switching in a backup system, etc.

The patterns that I discuss here are architectural patterns that describe the overall structure of an embedded system. Douglass (2002) describes lower-level, real-time design patterns that are used to help you make more detailed design decisions. These patterns include design patterns for execution control, communications, resource allocation, and safety and reliability.

These architectural patterns should be the starting point for an embedded systems design; however they are not design templates. If you use them as such, you will probably end up with an inefficient process architecture. You therefore have to optimize the process structure to ensure that you do not have too many processes. You also should ensure that there is a clear correspondence between the processes and the sensors and actuators in the system.

 

Observe and React

Monitoring systems are an important class of embedded real-time systems. A monitoring system examines its environment through a set of sensors and, usually, displays the state of the environment in some way. This could be on a built-in screen, on special-purpose instrument displays or on a remote display. If some exceptional event or sensor state is detected by the system, the monitoring system takes some action. Often, this involves raising an alarm to draw an operator’s attention to the event. Sometimes the system may initiate some other preventative action, such as shutting down the system to preserve it from damage.

 

9B.JPG

Figure 2

 

The Observe and React pattern (Figure 1 and Figure 2) is a pattern that is commonly used in monitoring systems. The values of sensors are observed and when particular values are detected, the system reacts in some way. Monitoring systems may be composed of several instantiations of the Observe and React pattern, one for each type of sensor in the system. Depending on the system requirements, you may then optimize the design by combining processes (e.g., you may use a single display process to display the information from all of the different types of sensors).

As an example of the use of this pattern, consider the design of a burglar alarm system that might be installed in an office building :

A software system is to be implemented as part of a burglar alarm system for commercial buildings. This uses several different types of sensors. These include movement detectors in individual rooms, door sensors that detect corridor doors opening, and window sensors on ground-floor windows that can detect when a window has been opened.

When a sensor detects the presence of an intruder, the system automatically calls the local police and, using a voice synthesizer, reports the location of the alarm. It switches on lights in the rooms around the active sensor and sets off an audible alarm. The sensor system is normally powered by mains power but is equipped with a battery backup. Power loss is detected using a separate power circuit monitor that monitors the mains voltage. If a voltage drop is detected, the system assumes that intruders have interrupted the power supply so an alarm is raised.

 

9%20C.JPG

Figure 3

 

A possible process architecture for the alarm system is shown in Figure 3. In this diagram, the arrows represent signals sent from one process to another. This system is a ‘soft’ real-time system that does not have stringent timing requirements. The sensors do not need to detect high-speed events, so they need only be polled relatively infrequently. The timing requirements for this system are covered.

I have already introduced the stimuli and responses in this alarm system. These are used as a starting point for the system design. The Observe and React pattern is used in this design. There are observer processes associated with each type of sensor and reactor processes for each type of reaction. There is a single analysis process that checks the data from all of the sensors. The display processes in the pattern are combined into a single display process.

Associated Kursus: KI142303BKI142303B
[ Mengubah: Saturday, 7 January 2017, 10:18 ]
 
Anyone in the world

Real Time Operating Systems

The execution platform for most application systems is an operating system that manages shared resources and provides features such as a file system, run-time process management, etc. However, the extensive functionality in a conventional operating system takes up a great deal of space and slows down the operation of programs. Furthermore, the process management features in the system may not be designed to allow fine-grain control over the scheduling of processes.

For these reasons, standard operating systems, such as Linux and Windows, are not normally used as the execution platform for real-time systems. Very simple embedded systems may be implemented as ‘bare metal’ systems. The systems themselves include system startup and shutdown, process and resource management, and process scheduling. More commonly, however, embedded applications are built on top of a real time operating system (RTOS), which is an efficient operating system that offers the features needed by real-time systems. Examples of RTOS are Windows/CE, Vxworks, and RTLinux.

 

8A.JPG

Figure 1

 

A real-time operating system manages processes and resource allocation for a realtime system. It starts and stops processes so that stimuli can be handled and allocates memory and processor resources. The components of an RTOS (Figure 1) depend on the size and complexity of the real-time system being developed. For all except the simplest systems, they usually include :

  1. A real-time clock, which provides the information required to schedule processes periodically.
  2. An interrupt handler, which manages aperiodic requests for service.
  3. A scheduler, which is responsible for examining the processes that can be executed and choosing one of these for execution.
  4. A resource manager, which allocates appropriate memory and processorresources to processes that have been scheduled for execution.
  5. A dispatcher, which is responsible for starting the execution of processes.

Real-time operating systems for large systems, such as process control or telecommunication systems, may have additional facilities, namely disk storage management, fault management facilities that detect and report system faults, and a configuration manager that supports the dynamic reconfiguration of real-time applications.

 

Process Management

Real-time systems have to handle external events quickly and, in some cases, meet deadlines for processing these events. This means that the event-handling processes must be scheduled for execution in time to detect the event. They must also be allocated sufficient processor resources to meet their deadline. The process manager in an RTOS is responsible for choosing processes for execution, allocating processor and memory resources, and starting and stopping process execution on a processor.

The process manager has to manage processes with different priorities. For some stimuli, such as those associated with certain exceptional events, it is essential that their processing should be completed within the specified time limits. Other processes may be safely delayed if a more critical process requires service. Consequently, the RTOS has to be able to manage at least two priority levels for system processes :

  1. Interrupt level This is the highest priority level. It is allocated to processes that need a very fast response. One of these processes will be the real-time clock process.
  2. Clock level This level of priority is allocated to periodic processes.

There may be a further priority level allocated to background processes (such as a self checking process) that do not need to meet real-time deadlines. These processes are scheduled for execution when processor capacity is available.

Within each of these priority levels, different classes of process may be allocated different priorities. For example, there may be several interrupt lines. An interrupt from a very fast device may have to pre-empt processing of an interrupt from a slower device to avoid information loss. The allocation of process priorities so that all processes are serviced in time usually requires extensive analysis and simulation.

Periodic processes are processes that must be executed at specified time intervals for data acquisition and actuator control. In most real-time systems, there will be several types of periodic process. Using the timing requirements specified in the application program, the RTOS arranges the execution of periodic processes so that they can all meet their deadlines.

 

8B.JPG

Figure 2

 

The actions taken by the operating system for periodic process management are shown in Figure 2. The scheduler examines the list of periodic processes and selects a process to be executed. The choice depends on the process priority, the process periods, the expected execution times, and the deadlines of the ready processes. Sometimes, two processes with different deadlines should be executed at the same clock tick. In such a situation, one process must be delayed. Normally, the system will choose to delay the process with the longest deadline.

Processes that have to respond quickly to asynchronous events may be interruptdriven. The computer’s interrupt mechanism causes control to transfer to a predetermined memory location. This location contains an instruction to jump to a simple and fast interrupt service routine. The service routine disables further interrupts to avoid being interrupted itself. It then discovers the cause of the interrupt and initiates, with a high priority, a process to handle the stimulus causing the interrupt. In some high-speed data acquisition systems, the interrupt handler saves the data that the interrupt signaled was available in a buffer for later processing. Interrupts are then enabled again and control is returned to the operating system.

At any one time, there may be several processes, all with different priorities, that could be executed. The process scheduler implements system-scheduling policies that determine the order of process execution. There are two commonly used scheduling strategies :

  1. Non-pre-emptive scheduling Once a process has been scheduled for execution it runs to completion or until it is blocked for some reason, such as waiting for input. This can cause problems, however, when there are processes with different priorities and a high-priority process has to wait for a low-priority process to finish.
  2. Pre-emptive scheduling The execution of an executing process may be stopped if a higher-priority process requires service. The higher-priority process preempts the execution of the lower-priority process and is allocated to a processor.

Within these strategies, different scheduling algorithms have been developed. These include round-robin scheduling, where each process is executed in turn, rate monotonic scheduling, where the process with the shortest period (highest frequency) is given priority; and shortest deadline first scheduling, where the process in the queue with the shortest deadline is scheduled (Burns and Wellings, 2009).

Information about the process to be executed is passed to the resource manager. The resource manager allocates memory and, in a multiprocessor system, also adds a processor to this process. The process is then placed on the ‘ready list’, a list of processes that are ready for execution. When a processor finishes executing a process and becomes available, the dispatcher is invoked. It scans the ready list to find a process that can be executed on the available processor and starts its execution.

Associated Kursus: KI142303BKI142303B
 
Anyone in the world

Concurrent Models

The concurrent development model, sometimes called concurrent engineering, allows a software team to represent iterative and concurrent elements of any of the process models described in this chapter. For example, the modeling activity defined for the spiral model is accomplished by invoking one or more of the following software engineering actions: prototyping, analysis, and design.

 

7.JPG

 Figure 1

 

Figure 1 provides a schematic representation of one software engineering activity within the modeling activity using a concurrent modeling approach. The activity modeling may be in any one of the states12 noted at any given time. Similarly, other activities, actions, or tasks (e.g., communication or construction) can be represented in an analogous manner. All software engineering activities exist concurrently but reside in different states.

For example, early in a project the communication activity (not shown in the figure) has completed its first iteration and exists in the awaiting changes state. The modeling activity (which existed in the inactive state while initial 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 modeling activity moves from the under development state into the awaiting changes state.

Concurrent modeling 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, actions, and tasks to a sequence of events, it defines a process network. Each activity, action, or task on the network exists simultaneously with other activities, actions, or tasks. Events generated at one point in the process network trigger transitions among the states.


A Final Word on Evolutionary Processes

I have already noted that modern computer software is characterized by continual change, by very tight time lines, and by an emphatic need for customer user satisfaction. In many cases, time-to-market is the most important management requirement. If a market window is missed, the software project itself may be meaningless. Evolutionary process models were conceived to address these issues, and yet, as a general class of process models, they too have weaknesses. These are summarized by Nogueira and his colleagues [Nog00] :

Despite the unquestionable benefits of evolutionary software processes, we have some concerns. The first concern is that prototyping [and other more sophisticated evolutionary processes] poses a problem to project planning because of the uncertain number of cycles required to construct the product. Most project management and estimation techniques are based on linear layouts of activities, so they do not fit completely.

Second, evolutionary software processes do not establish the maximum speed of the evolution. If the evolutions occur too fast, without a period of relaxation, it is certain that the process will fall into chaos. On the other hand if the speed is too slow then productivity could be affected.

Third, software processes should be focused on flexibility and extensibility rather than on high quality. This assertion sounds scary. However, we should prioritize the speed of the development over zero defects. Extending the development in order to reach high quality could result in a late delivery of the product, when the opportunity niche has disappeared.

This paradigm shift is imposed by the competition on the edge of chaos. Indeed, a software process that focuses on flexibility, extensibility, and speed of development over high quality does sound scary. And yet, this idea has been proposed by a number of well respected software engineering experts (e.g., [You95], [Bac97]). The intent of evolutionary models is to develop high-quality software14 in an iterative or incremental manner.

However, it is possible to use an evolutionary process to emphasize flexibility, extensibility, and speed of development. The challenge for software teams and their managers is to establish a proper balance between these critical project and product parameters and customer satisfaction (the ultimate arbiter of software quality).

Associated Kursus: KI142303BKI142303B
 
Halaman: () 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 ... 41 ()