2.

Explain why incremental development is the most effective approach for developing
business
software systems. Why is this model less appropriate for real-time systems engineering?
Business software systems usually complex, software intensive, and frequently being
changes when business goals or processes are changed. So incremental development is
better.
Real-time systems usually involve many hardware components which are not easy to
change and cannot be incremental. Also real-time systems usually safety critical which
needed be built based on well planned process.

Chapter 2: Software Process

Software Engineering 9

2.1 Giving reasons for your answer based on the type ofsystem beingdeveloped, suggest the most
appropriate generic software process modelthat might be used as a basis for managing the
development of thefollowing systems:
A system to control anti-lock braking in a car:

 Anti-lock braking system:This is a safety-critical system so requires a lot ofup-front

analysis before implementation. It certainly needs a plan-drivenapproach to development
with the requirements carefully analyzed. Awaterfall model is therefore the most
appropriate approach to use, perhapswith formal transformations between the different
development stages.

A university accounting system that replaces an existing system:

 University accounting system:This is a system whose requirements arefairly well-known

and which will be used in an environment in conjunctionwith lots of other systems such
as a research grant management system.Therefore, a reuse-based approach is likely to be
appropriate for this.
A virtual reality system to support softwaremaintenance:

 Virtual reality system:This is a system where the requirements will changeand there will
be an extensive user interface components. Incrementaldevelopment with, perhaps, some
UI prototyping is the most appropriatemodel. An agile process may be used.

An interactive travel planning system that helps users plan journeyswith the lowest
environmental impact:

 Interactive travel planning system: System with a complex user interface butwhich must
be stable and reliable. An incremental development approach isthe most appropriate as
the system requirements will change as real userexperience with the system is gained.

2.3 Consider the reuse-based process model shown in Figure 2.3. Explain why itis essential to
have two separate requirements engineering activities in theprocess.

 In a reuse based process, you need two requirements engineering activities becauseit is
essential to adapt the system requirements according to the capabilities of
thesystem/components to be reused. These activities are:
 1. An initial activity where you understand the function of the system and setout broad
requirements for what the system should do. These should beexpressed in sufficient detail
that you can use them as a basis for deciding ofa system/component satisfies some of the
requirements and so can be reused.
 2. Once systems/components have been selected, you need a more detailedrequirements
engineering activity to check that the features of the reusedsoftware meet the business
needs and to identify changes and additions that are required.
2.4 Suggest why it is important to make a distinction between developing theuser requirements
and developing system requirements in the requirementsengineering process.

 There is a fundamental difference between the user and the system requirementsthat
mean they should be considered separately.
 1. The user requirements are intended to describe the system’s functions andfeatures from
a user perspective and it is essential that users understandthese requirements. They should
be expressed in natural language and maynot be expressed in great detail, to allow some
implementation flexibility.The people involved in the process must be able to understand
the user’s environment and application domain.

2.4 Cont’d

 2. The system requirements are much more detailed than the user requirementsand are
intended to be a precise specification of the system that may be partof a system contract.
They may also be used in situations wheredevelopment is outsourced and the
development team need a completespecification of what should be developed. The
system requirements aredeveloped after user requirements have been established.

2.6 Explain why change is inevitable in complex systems andgive examples(apart from
prototyping and incremental delivery) of software processactivities that help predict changes and
make the software being developedmore resilient to change.

 Systems must change because as they are installed in an environment theenvironment

adapts to them and this adaptation naturally generates new/differentsystem
requirements.Furthermore, the system\'s environment is dynamic andconstantly generates
new requirements as a consequence of changes to thebusiness, business goals and
business policies. Unless the system is adapted toreflect these requirements, its facilities
 will become out-of-step with the facilitiesneeded to support the business and, hence, it
will become less useful.

2.6 Cont’d

 Examples of process activities that support change are:

 1. Recording of requirements rationale so that the reason why a requirement isincluded is
known. This helps with future change.
 2. Requirements traceability that shows dependencies between requirementsand between
the requirements and the design/code of the system.
 3. Design modeling where the design model documents the structure of the software.
 4. Code refactoring that improves code quality and so makes it more amenable to change.

2.9 What are the advantages of providing static and dynamic views of thesoftware process as
in the Rational Unified Process?

 An approach to process modeling which is simply based on static activities, such

asrequirements, implementation, etc. forces these activities to be set out in a
sequencewhich may not reflect the actual way that these are enacted in any one
organization.
 In most cases, the static activities shown in Figure 2.13 are actually interleaved so
asequential process model does not accurately describe the process used. Byseparating
these from the dynamic perspective i.e. the phases of development, youcan then discuss
how each of these static activities may be used at each phase of theprocess.
 Furthermore, some of the activities that are required during some of thesystem phases are
in addition to the central static activities shown in Figure 2.13.These vary from one
organization to another and it is not appropriate to impose aparticular process in the
model.
2.1 Memberikan alasan untuk jawaban Anda berdasarkan jenis sistem yang dikembangkan,
menyarankan model proses perangkat lunak generik yang paling tepat yang dapat digunakan
sebagai dasar untuk mengelola pengembangan sistem berikut:
Sebuah sistem untuk mengendalikan penguncian anti-lock di dalam mobil:

• Sistem pengereman anti-lock: Ini adalah sistem yang sangat penting sehingga memerlukan
banyak analisis kedepannya sebelum di implementasikan. Sistem Ini tentu membutuhkan
pendekatan berbasis rencana untuk pengembangan dengan persyaratan yang dianalisis dengan
cermat. Oleh karena itu, model air terjun adalah pendekatan yang paling tepat untuk digunakan,
mungkin dengan transformasi formal antara tahap pengembangan yang berbeda

Sistem akuntansi universitas yang menggantikan sistem yang ada:

• Sistem akuntansi universitas: Ini adalah sistem yang persyaratannya cukup terkenal dan akan
digunakan di lingkungan bersamaan dengan banyak sistem lain seperti sistem pengelolaan hibah
penelitian. Oleh karena itu, pendekatan berbasis ulang mungkin sesuai untuk ini.

Sebuah sistem virtual reality untuk mendukung softwaremaintenance:

• Virtual reality system: Ini adalah sistem dimana persyaratan akan berubah dan akan ada
komponen antarmuka pengguna yang ekstensif. Incrementaldevelopment dengan, mungkin,
beberapa prototyping UI adalah yang paling sesuai. Proses tangkas bisa digunakan.

Sistem perencanaan perjalanan interaktif yang membantu pengguna merencanakan perjalanan

dengan dampak lingkungan terendah:
• Sistem perencanaan perjalanan interaktif: Sistem dengan antarmuka pengguna yang rumit
namun harus stabil dan dapat diandalkan. Pendekatan pengembangan inkremental paling sesuai
karena persyaratan sistem akan berubah sebagai pengalaman nyata dengan sistem diperoleh.

2.2 Jelaskan mengapa pengembangan inkremental adalah pendekatan yang paling efektif untuk
mengembangkan bisnis
sistem perangkat lunak Mengapa model ini kurang tepat untuk rekayasa sistem real-time?
Sistem perangkat lunak bisnis biasanya rumit, intensif perangkat lunak, dan sering berubah saat
tujuan atau proses bisnis berubah. Jadi perkembangan inkremental lebih baik.
Sistem real-time biasanya melibatkan banyak komponen perangkat keras yang tidak mudah
berubah dan tidak bisa bersifat incremental. Juga sistem real-time biasanya keselamatan kritis
yang perlu dibangun berdasarkan proses yang direncanakan dengan baik.
2.3 Pertimbangkan model proses berbasis reuse yang ditunjukkan pada Gambar 2.3. Jelaskan
mengapa penting untuk memiliki dua persyaratan teknik yang terpisah dalam proses.
• Dalam proses berbasis reuse, Anda memerlukan dua persyaratan kegiatan teknik karena sangat
penting untuk menyesuaikan persyaratan sistem sesuai kemampuan sistem / komponen yang
akan digunakan kembali. Kegiatan ini adalah:
• 1. Aktivitas awal di mana Anda memahami fungsi sistem dan menetapkan persyaratan yang
luas untuk apa yang seharusnya dilakukan sistem. Ini harus dijelaskan dengan cukup rinci
sehingga Anda dapat menggunakannya sebagai dasar untuk menentukan sistem / komponen yang
memenuhi beberapa persyaratan dan dapat digunakan kembali.
• Setelah sistem / komponen dipilih, Anda memerlukan aktivitas teknik yang lebih rinci untuk
memeriksa apakah fitur perangkat lunak yang digunakan ulang memenuhi kebutuhan bisnis dan
untuk mengidentifikasi perubahan dan penambahan yang diperlukan.

2.4 Sarankan mengapa penting untuk membuat perbedaan antara pengembangan persyaratan
pengguna dan persyaratan sistem pengembangan dalam proses rekayasa persyaratan.
• Ada perbedaan mendasar antara pengguna dan persyaratan sistem yang berarti harus
dipertimbangkan secara terpisah.
• 1. Persyaratan pengguna dimaksudkan untuk menggambarkan fungsi dan fungsi sistem dari
perspektif pengguna dan sangat penting bahwa pengguna memahami persyaratan ini. Mereka
harus dinyatakan dalam bahasa alami dan mungkin tidak diungkapkan dengan sangat rinci, untuk
memungkinkan fleksibilitas implementasi. Orang-orang yang terlibat dalam proses ini harus
dapat memahami lingkungan pengguna dan domain aplikasi.

2. Persyaratan sistem jauh lebih rinci daripada persyaratan pengguna dan dimaksudkan sebagai
spesifikasi sistem yang tepat yang mungkin merupakan bagian dari kontrak sistem. Mereka juga
dapat digunakan dalam situasi dimana pengembangan dilakukan secara outsource dan tim
pengembang memerlukan penjelasan lengkap tentang apa yang harus dikembangkan. Persyaratan
sistem dikembangkan setelah persyaratan pengguna ditetapkan.

2.6 Jelaskan mengapa perubahan tidak dapat dielakkan dalam sistem yang kompleks dan contoh
yang mudah (terlepas dari pemberian prototipe dan inkremental) aktivitas perangkat lunak yang
membantu memprediksi perubahan dan membuat perangkat lunak dikembangkan lebih tangguh
untuk berubah.
• Sistem harus berubah karena karena dipasang di lingkungan, lingkungan menyesuaikan diri
dengan mereka dan adaptasi ini secara alami menghasilkan persyaratan sistem baru / berbeda.
Selanjutnya, lingkungan sistemnya dinamis dan terus menghasilkan persyaratan baru sebagai
konsekuensi perubahan pada bisnis, sasaran bisnis dan kebijakan bisnis. Jika sistem tidak
disesuaikan dengan kebutuhan ini, fasilitasnya akan menjadi tidak sesuai dengan fasilitas yang
dibutuhkan untuk mendukung bisnis dan karenanya akan menjadi kurang berguna.
Contoh kegiatan proses yang mendukung perubahan adalah:
• 1. Pencatatan persyaratan rasional sehingga alasan mengapa suatu persyaratan disertakan
diketahui. Ini membantu perubahan masa depan.
• 2. Persyaratan ketertelusuran yang menunjukkan ketergantungan antara persyaratan dan antara
persyaratan dan disain / kode sistem.
• 3. Perancangan desain dimana model perancangan mendokumentasikan struktur perangkat
lunak.
• 4. Kode refactoring yang meningkatkan kualitas kode dan membuatnya lebih mudah berubah.

2.9 Apa keuntungan dari menyediakan tampilan dinamis dan dinamis dari proses perangkat
lunak seperti dalam Rational Unified Process?
• Pendekatan untuk memproses pemodelan yang hanya didasarkan pada aktivitas statis, seperti
tuntutan, implementasi, dan lain-lain memaksa kegiatan ini untuk ditetapkan dalam sekuel yang
mungkin tidak mencerminkan cara sebenarnya yang diberlakukan dalam organisasi mana pun.
• Pada kebanyakan kasus, aktivitas statis yang ditunjukkan pada Gambar 2.13 benar-benar
disisipkan sehingga model proses yang tidak sama tidak secara akurat menggambarkan proses
yang digunakan. Byseparating ini dari perspektif dinamis yaitu fase perkembangan, Anda
kemudian dapat mendiskusikan bagaimana masing-masing kegiatan statis ini dapat digunakan
pada setiap tahap proses.
• Selanjutnya, beberapa aktivitas yang diperlukan selama beberapa fase sistem adalah sebagai
tambahan terhadap aktivitas statik sentral yang ditunjukkan pada Gambar 2.13. Ini berbeda dari
satu organisasi ke organisasi lainnya dan tidak tepat untuk menerapkan proses pembedahan pada
model.