Anda di halaman 1dari 7

()In the introduction to this chapter Baetjer notes: "The process provides

interaction between users and designers, between users and evolving tools, and
between designers and evolving tools [technology]." List five questions that (1)
designers should ask users, (2) users should ask designers, (3) users should ask
themselves about the software product that is to be built, (4) designers should ask
themselves about the software product that is to be built and the process that will
be used to build it.Designers should ask users: Is the product satisfactory, or
does it require redesign or rework?
Was user input solicited, to avoid the product being unsatisfactory and requiring
rework?

Apakah ada kebutuhan akan persyaratan baru?


Apakah produk lebih besar dari perkiraan?
Apakah modul membutuhkan lebih banyak pengujian, disain dan pelaksanaan kerja yang
benar
dari yang diharapkan?

Pengguna harus bertanya sebagai desainer:


Apakah ruang lingkupnya jelas?
Apakah kita memiliki alat dan orang dengan keterampilan yang dibutuhkan untuk
pengembangan?
Apakah persyaratan didefinisikan dengan benar, adalah persyaratan tambahan yang
dibutuhkan.
Apakah modul memerlukan lebih banyak pengujian, desain? Pengguna harus bertanya
pada diri sendiri tentang produk perangkat lunak yang akan dibangun:
Berapakah ruang lingkup dan tujuan produk perangkat lunak?
Apakah produk lebih besar dari perkiraan?
Apakah orang terbaik tersedia?
Apakah staf berkomitmen dan memiliki keterampilan yang dibutuhkan?
Akankah omzet antar anggota staf cukup rendah untuk memungkinkan kontinuitas?

Perancang harus bertanya pada diri sendiri tentang produk perangkat lunak yang akan
dibangun dan proses yang akan digunakan untuk membangunnya:
Lingkup dan tujuan dokumen?
Alat apa yang akan digunakan?
Apa tujuan dan prioritas risk aversion?
Apa yang akan menjadi langkahnya

Is there a need for new requirements?


Is the product larger than estimated?
Do the modules require more testing, design and implementation work to correct
than expected?

Users should ask as designers:


Is the scope clear?
Do we have the tools and people with skills required for the development?
Are the requirements properly defined, are additional requirements needed.
Are the specified areas of the product more time consuming than usual? Does the
module require more testing, design? Users should ask themselves about the software
product that is to be built:
What is the scope and purpose of the software product?
Is the product larger than estimated?
Are the best people available?
Is the staff committed and possess skills required?
Will the turnover among staff members be low enough to allow continuity?

Designers should ask themselves about software product that is to be built and the
process that will used to build it:
Scope and purpose of the document?
What tools are to be used?
What are the objectives and risk aversion priorities?
What will be the steps

()Try to develop a set of actions for the communication activity. Select one action
and define a task set for it.

Set Tugas untuk Aktivitas Komunikasi: Kumpulan tugas akan menentukan pekerjaan
aktual yang harus dilakukan untuk mencapai tujuan tindakan rekayasa perangkat
lunak.
Untuk kegiatan komunikasi ini adalah:
Buat daftar pemangku kepentingan untuk proyek ini
Mengundang semua pemangku kepentingan ke pertemuan informal
Mintalah mereka membuat daftar fitur dan fungsinya
Diskusikan persyaratan dan buat daftar akhir
Prioritaskan persyaratan dan perhatikan bahwa tugas ini mungkin lebih besar
daripada proyek perangkat lunak yang kompleks, mungkin kemudian disertakan untuk
melakukan serangkaian pertemuan spesifikasi, membuat daftar fungsi dan fitur awal
berdasarkan masukan dari pemangku kepentingan.
Untuk membangun daftar persyaratan pemangku kepentingan yang direvisi
Gunakan teknik penyebaran fungsi kualitas untuk memprioritaskan persyaratan.
Perhatikan batasan dan batasan pada sistem.
Diskusikan metode untuk memvalidasi sistem.

Task Set for Communication Activity: A task set would define the actual work to be
done to accomplish the objectives of a software engineering action.
For the communication activity these are:
Make a list of stakeholders for the project
Invite all the stakeholders to an informal meeting
Ask them to make a list of features and functions
Discuss requirements and build a final list
Prioritize requirements and note the areas that he is uncertain of these tasks may
be larger for a complex software project, they may then include to conduct a series
of specification meetings, build a preliminary list of functions and features based
on stakeholder input.
To build a revised list of stake holder requirements Use quality function
deployment techniques to prioritize the requirements.
Note constraints and restrictions on the system.
Discuss methods for validating system.

()A common problem during communication occurs when you encounter two stakeholders
who have conflicting ideas about what the software should be. That is, you have
mutually conflicting requirements. Develop a process pattern (this would be a stage
pattern) using the template presented in Section 2.1.3 that addresses this problem
and suggest an effective approach to it.

Nama pola
Persyaratan Pemangku Kepentingan yang Bertentangan. Pola pendekatan untuk
menyelesaikan konflik antara pemangku kepentingan selama aktivitas kerangka
komunikasi.
Jenis.
Pola panggung Konteks awal.
(1) Pemangku kepentingan telah diidentifikasi; (4) pemahaman awal lingkup proyek,
persyaratan bisnis dasar (3) masalah perangkat lunak utama yang harus diselesaikan
oleh tim perangkat lunak telah ditetapkan; dan kendala proyek telah dikembangkan.
Masalah.
Pemangku kepentingan meminta fitur yang saling bertentangan untuk produk perangkat
lunak yang sedang dikembangkan.
Solusi.
Semua pemangku kepentingan diminta untuk memprioritaskan semua persyaratan sistem
yang diketahui, dengan resolusi untuk mempertahankan persyaratan pemangku
kepentingan dengan prioritas tertinggi dan / atau suara terbanyak.
Konteks yang dihasilkan
Daftar persyaratan yang diprioritaskan yang disetujui oleh pemangku kepentingan
dibentuk untuk memandu tim perangkat lunak dalam pembuatan prototip produk awal.
Pola terkait
Kolaborasi - definisi pedoman, Ruang Lingkup - isolasi, Pengkajian persyaratan,
Deskripsi Kendala, Persyaratan Penggunaan / Contoh yang Tidak Dikenal.
Komunikasi diwajibkan sepanjang proyek perangkat lunak.

Pattern Name. Conflicting Stakeholder Requirements Intent. This pattern describes


an approach for resolving conflicts between stakeholders during the communication
framework activity. Type. Stage pattern Initial context. (1) Stakeholders have been
identified; (2) Stakeholders and software engineers have established a
collaborative communication; (3) overriding software problem to be solved by the
software teams has been established; (4) initial understanding of project scope,
basic business requirements and project constraints has been developed.
Problem.
Stakeholders request mutually conflicting features for the software product under
development.
Solution.
All stakeholders asked to prioritize all known system requirements, with resolution
being to keep the stakeholder requirements with highest priorities and/or the most
votes.
Resulting Context. A prioritized list of requirements approved by the stakeholders
is established to guide the software team in the creation of an initial product
prototype.
Related Patterns. Collaborative--guideline definition, Scope--isolation,
Requirements gathering, Constraint Description, Requirements unclear
Known Uses/Examples.
Communication is mandatory throughout the software project.

()Do some research on PSP and present a brief presentation that describes the types
of measurements that an individual software engineer is asked to make and how those
measurement can be used to improve personal effectiveness.

()The use of scripts (a required mechanism in TSP) is not universally praised


within the software community. Make a list of pros and cons regarding scripts and
suggest at least two situations in which they would be useful and another two
situations where they might provide less benefit.

Setiap proyek dimulai dengan menggunakan urutan tugas yang mendefinisikan tim untuk
menetapkan dasar yang kuat untuk memulai proyek. Team Software Process (TSP)
memandu tim teknik yang mengembangkan produk intensif perangkat lunak. Menggunakan
TSP membantu organisasi membangun praktik rekayasa yang matang dan terdisiplin yang
menghasilkan perangkat lunak yang aman dan andal dalam waktu yang lebih singkat dan
dengan biaya lebih rendah. TSP menggunakan prinsip dan metode PSP untuk memberikan
konteks dalam melakukan pekerjaan teknik yang berorientasi timbal balik dan tim.
Tujuan TSP adalah untuk menyediakan kerangka kerja untuk membangun dan membimbing
tim semacam itu. TSP menggunakan beragam skrip, formulir, dan standar yang
berfungsi untuk membimbing anggota tim dalam pekerjaan mereka. Itu adalah bagian
dari pengujian (yaitu peluncuran proyek, perancangan, implementasi, integrasi dan
pengujian, dan postmortem) dan fungsi kerja yang lebih rinci lainnya (misalnya
perencanaan pembangunan, pengembangan persyaratan, manajemen konfigurasi perangkat
lunak, dan uji unit) proses tim. Tim TSP diluncurkan kembali secara berkala. Oleh
karena itu, proses TSP mengikuti strategi pengembangan yang berulang dan berulang,
pembuatan ulang berkala diperlukan sehingga setiap tahap atau siklus dapat
direncanakan berdasarkan pengetahuan yang diperoleh pada siklus sebelumnya.
Peluncuran ulang juga diperlukan untuk memperbarui rencana rinci para insinyur,
yang tepat untuk beberapa bulan.

Each project is initiated using a sequence of tasks (defined as a script) that


enables the team to establish a firm basis for starting the project. Team Software
Process (TSP) guides engineering teams that are developing software-intensive
products. Using TSP helps organizations establish a mature and disciplined
engineering practice that produces secure, reliable software in less time and at
lower costs. TSP uses the principles and methods of PSP to provide a context for
performing disciplined, team-oriented engineering work. The objective of TSP is to
provide a framework for building and guiding such teams. TSP makes use of a wide
variety of scripts, forms, and standards that serve to guide team members in their
work. Scripts define specific process activities (i.e., project launch, design,
implementation, integration and testing, and postmortem) and other more detailed
work functions (e.g., development planning, requirements development, software
configuration management, and unit test) that are part of the team process. TSP
teams are relaunched periodically. Because the TSP process follows an iterative and
evolving development strategy, periodic relaunches are necessary so that each phase
or cycle can be planned based on the knowledge gained in the previous cycle. The
relaunch is also required to update the engineers detailed plans, which are
usually accurate for only a few months.

()Read [Nog00] and write a two- or three-page paper that discusses the impact of
chaos on software engineering.

()Provide three examples of software projects that would be amenable to the


waterfall model. Be specific.

Model air terjun sesuai untuk proyek dengan karakteristik sebagai berikut:
(1) masalahnya dipahami dengan baik (persyaratan didefinisikan dengan baik);
(2) tanggal pengirimannya realistis;
(3) tidak mungkin perubahan besar dalam persyaratan akan diminta saat proyek
berjalan.

Contoh spesifiknya adalah:


(1) modifikasi yang benar terhadap program yang ada;
(2) implementasi perhitungan numerik atau aturan bisnis yang mudah, walaupun
kompleks;
(3) peningkatan yang terbatas pada program yang ada.

The waterfall model is appropriate for projects with the following characteristics:
(1) the problem is well understood (requirements are well-defined); (2) the
delivery date is realistic; (3) it's unlikely that major changes in requirements
will be requested as the project proceeds. Specific examples might be: (1) a well
understood modification to an existing program; (2) a straightforward
implementation of a numerical calculation or business rule, even if it's complex;
(3) a constrained enhancement to an existing program.

()Provide three examples of software projects that would be amenable to the


prototyping model. Be specific

Aplikasi perangkat lunak yang relatif mudah untuk prototipe hampir selalu
melibatkan interaksi manusia-mesin dan / atau grafis komputer yang berat.
Aplikasi lain yang kadang-kadang sesuai untuk prototyping adalah kelas algoritma
matematis tertentu, subset dari sistem berbasis perintah dan aplikasi lainnya
dimana hasilnya dapat dengan mudah diperiksa tanpa interaksi real-time.

Software applications that are relatively easy to prototype almost always involve
human-machine interaction and/or heavy computer graphics. Other applications that
are sometimes amenable to prototyping are certain classes of mathematical
algorithms, subset of command driven systems and other applications where results
can be easily examined without real-time interaction.

()What process adaptations are required if the prototype will evolve into a
deliverable system or product?

Ada tiga proses adaptasi yang dibutuhkan. Prosesnya adalah aturan desain yang lebih
ketat dan prosedur SQA harus diterapkan sejak awal, prototipe harus dirancang
dengan kemampuan diperpanjang, dan kemudian bahwa kerangka untuk ekstensi yang akan
menyebabkannya berkembang menjadi sistem produksi.

There are three process adaptations that are required if the prototype will evolve
into a deliverable system or product. The processes are more rigorous design rules
and SQA procedures must be applied from the beginning, the prototype must be
designed with extensibility in mind, and then it becomes the framework for
extensions that will cause it to evolve into a production system.

()Provide three examples of software projects that would be amenable to the


incremental model. Be specific.

Sistem pemeliharaan ATM


Perluasan ke permainan video game
Meluncurkan satelit baru

ATM maintenance system


An expansion to a game
Launching a new satellite

()As you move outward along the spiral process flow, what can you say about the
software that is being developed or maintained?

when software enginering team moves around the spiral, the first circuit around the
spiral results in development of product specification. The subsequent passes
around the spiral might be used to develop prototype in more subsequent manner. In
each pass, through planning region, some adjusments to project plan are made. Cost
and schedule adjustments can also be made according to costumer feedback.

()Is it possible to combine process models? If so, provide an example

In the first scenario we have used different modelling techniques depending on the
strength of each one. For example the use of BPMN to describe a detailed process
flow as a set of executable steps to be used in system development. We find that,
in general, BPMN doesnt do such a good job of bringing together the different
parts of the overall system. For this an approach such as IDEF0 is better at
visualising the high level systems into which you can drill through to the BPMN
models. I have used some systems that support this approach but there are usually
sacrifices to be made on usability of one model or the other.
In the second scenario we often see process models captured that isolate one
specific part of an overall process. Its typically argued that this is done in
order to simplify the model but I believe it is more to do with simplifying the act
of capture as these models end up creating more questions than they ever answer.
In a recent example a customer shared the end-to-end process for billing in a
customer project. At first glance this looked like a coherent flow. However, as we
tried to analyse it further it was clear that it was not a process at all but a
series of distinct activities that were triggered at different parts of the core
project delivery process. As these activities had all been joined together using
flow lines it was impossible to see how and when these activities were triggered.
So all we really had was a list of some activities that happened but no real
understanding of how and when.
Again the solution to this was to look at the overall project delivery
process from a systemic point of view. We used an IDEF0 like approach to build a
holistic model of the project delivery process so we could see exactly when and how
all activities are triggered. In a sense we combined what had been a set of
individual process models. In reality it was quicker to start from scratch and use
an approach that was more suitable.

()The concurrent process model defines a set of states. Describe what these
states represent in your own words, and then indicate how they come into play
within the concurrent process model.

Dalam model proses concurrent memiliki tujuh tahapan (tidak aktif, dalam
pengembangan, menunggu perubahan, dalam revisi, yang sedang dikaji, dilakukan
secara mendasar, dilakukan) mewakili mode perilaku aktivitas rekayasa perangkat
lunak yang dapat diamati secara eksternal.
Dalam model proses bersamaan semua aktivitas rekayasa perangkat lunak ada pada saat
bersamaan, namun setiap aktivitas berada dalam keadaan berbeda untuk membentuk
jaringan proses.
Transisi antara keadaan yang berbeda dari setiap aktivitas rekayasa perangkat lunak
dipicu oleh serangkaian peristiwa yang telah ditentukan.

In the concurrent process model the seven states (inactive, under development,
awaiting changes, under revision, under review, baselined, done) represent the
externally observable mode of behaviour of a specific software engineering
activity. In the concurrent process model all the software engineering activities
exist at the same time, but each activity is in a different state to form a process
network. The transition between different states of each software engineering
activity is triggered by a series of predefined events.

()What are the advantages and disadvantages of developing software in which quality
is good enough? That is, what happens when we emphasize development speed over
product quality?

Keuntungan Meningkatkan keterampilan kepemimpinan dan manajemen dengan meningkatkan


pengembangan diri.
Menciptakan suasana yang sadar akan kualitas. Berfungsi sebagai inti
pengendalian kualitas perusahaan di tingkat bengkel.
Meningkatkan moral karyawan dan rasa tujuan bersama. Karyawan perlu
berpendidikan dan memiliki pemahaman yang baik tentang organisasi di luar wilayah
kerja sendiri.
Lingkaran kualitas biaya yang efektif Membebaskan manajemen - Petugas lantai
toko paling baik untuk mengidentifikasi masalah.
Kekurangan Intensitas kerja meningkat - karena lebih banyak masalah yang
dipecahkan lebih diharapkan pekerja.
Bisa dikenalkan untuk alasan yang salah yaitu. Sikap berubah.
Manajemen perlu berkomitmen penuh terhadap sistem mutu jika solusi yang tidak
dilaksanakan bisa membuat frustrasi peserta.
Dapat memiliki efek negatif pada hubungan industrial.
Bisa fokus pada masalah biasa.

Advantages Improve leadership and management skills by increased self


development. Creates an atmosphere conscious of quality. Function as a nucleus
for company wide quality control at the workshop level. Increases employee morale
and sense of common goal. Employees need to be well educated and have a good
understanding of the organisation beyond own work area. Quality circles cost
effective. Frees management -shop floor workers best located to identify problems.
Disadvantages Intensity of work increases -as more problems are solved more is
expected of workers. Can be introduced for incorrect reasons ie. attitude change.
Management needs to be fully committed to quality systems -if solutions not
implemented can be frustrating for participants. Can have a negative effect on
industrial relations. Can focus on mundane problems.

()Provide three examples of software projects that would be amenable to the


component based model. Be specific.

Perangkat lunak perbankan


Pengendali lalu lintas kereta bawah tanah
Sistem informasi mobile kepolisian

Banking software
Subway traffic controllers
Police mobile information system

()It is possible to prove that a software component and even an entire program is
correct. So why doesnt everyone do this?

Tidak. Anda hanya bisa menyatakan kebenaran sampai tingkat kepastian. Tingkatan itu
mungkin sangat tinggi, terutama untuk rutinitas yang sangat singkat, tapi tidak ada
yang bisa membuktikan kebenarannya sampai 100%.

No. You can only state correctness to a degree of certainty. That degree might be
very high, particularly for a very short routine, but no one can prove correctness
to 100%.

()Are the Unified Process and UML the same thing? Explain your answer.

Tidak, mereka bukan hal yang sama.


UML dalam bahasa pemodelan yang digunakan untuk UML dalam proses pengembangan
perangkat lunak. UML adalah bahasa pemodelan yang mendukung praktik rekayasa
perangkat lunak berorientasi objek.
UML digunakan dalam proses terpadu.
UML tidak menyediakan kerangka proses untuk memandu tim proyek.

No, they are not the same thing. The Unified process is a type of framework that is
used for UML in software engineering. It is a software development process which
should be customized for specific project. UML is a modeling language that supports
object oriented software engineering practice.
UML is used in the unified process.
UML does not provide the process framework to guide project teams.