Kelas : CE-4B
NIM : 1405113001
Sudahkah anda Tahu?
Thursday, June 25, 2015
Tuesday, October 21, 2014
Tugas - Summary
1.3 Summar
– The problem domain for software
engineering is industrial-strength software. This software is meant to solve
some problem of some set of users, and is expected to be of high quality.
– In
this problem domain, cost, schedule, and quality are basic driving forces.
–
Productivity is measured as amount of output per unit of input resource
–
Software quality has many attributes which include functionality, reliabil-
ity, usability, efficiency,
maintainability, and portability
– The
problems in this domain often tend to be very large and where the needs of the
customers change fast
Self-Assessment
Exercises
1.What
are the main differences
between a student software and industrial-strength software?
2.
Where do you think this extra effort
cost is spent?
3.
What measurements will you take in a project to measure the productivity?
4.
What are the different
attributes of software quality?
5. What are some of the project management
tasks that you will do differently
for a large project as compared to a small project?
6. Suppose changes are to be made to a
software system that is in operation.
2. Software Prosses
Software engineering
is defined as the systematic approach to the development, operation,
maintenance, and retirement of software. eration, maintenance, and retirement
of software [52]. We have seen that besides delivering software, high quality,
low cost, and low cycle time are also goals which software engineering must
achieve. As it is people who ultimately develop and deliver (and productivity
is measured with respect to people’s effort
as the basic input), the main job of processes is to help people achieve higher
Q&P by specifying what tasks to do and how to do them.
As processes form the heart of
software engineering, with tools and tech- nology providing support to efficiently execute the processes,
this book focuses primarily on processes. In this chapter we will discuss:
– Role of a process and a process
model in a project.
– Various component processes in
the software process and the key role of the development process and the
project management process.
– Various models for the
development process—waterfall, prototyping, itera- tive, RUP, timeboxing, and
XP.
– The overall structure of the
project management process and its key phases.
2.1 Process and Project
A
software project is one instance of this problem, and the development process
is what is used to achieve this purpose. The role of process increases due to
these additional goals, and though many processes can achieve the basic.
Figure 2.1 Basic problem
A
process model specifies a general process, which is “optimum” for a class of
projects. That is, in the situations for which the model is applicable, using
the process model as the project’s process will lead to the goal of developing
software with high Q&P.
2.2 Component Software
Processes
As
defined above, a process is the sequence of steps executed to achieve a goal.
Since many different
goals may have to be satisfied while developing soft- ware, multiple processes
are needed.
The
processes that deal with the technical and management issues of soft- ware
development are collectively called the software process. During the project
many products are produced which are typically com- posed of many items (for
example, the final source code may be composed of many source files). The
objective of this component process is to primarily deal with managing change,
so that the integrity of the products is not violated despite changes.
These
three constituent processes focus on the projects and the products and can be
considered as comprising the product engineering processes, as their main
objective is to produce the desired product. The basic objective of the process
management process is to improve the software process. By improvement, we mean that
the capability of the process to produce quality goods at low cost is improved.
The relationship between these major component processes is shown in Fig- ure
2.2. These component processes are distinct not only in the type of activities
performed in them, but typically also in the people who perform the activities
specified by the process.
Figure 2.2 Software Prosses
For
the rest of the book, we will use the term software process to mean product
engineering processes, unless specified otherwise.
2.3 Software
Development Process Models
A
project’s development process defines the tasks the project should per- form,
and the order in which they should be done. A process limits the degrees of
freedom for a project by specifying what types of activities must be under-
taken and in what order, such that the “shortest” (or the most efficient) path is obtained from the
user needs to the software satisfying these needs.
As
discussed earlier, a process model specifies a general process, usually as a set
of stages in which a project should be divided, the order in which the stages
should be executed, and any other constraints and conditions on the execution
of stages.
2.3.1
Waterfall Model
The
basic idea behind the phases is separation of concerns—each phase deals with a
distinct and separate set of concerns. By doing this, the large and complex
task of building the software is broken into smaller tasks (which, by
themselves, are still quite complex) of specifying requirements, doing design,
etc. Separating the concerns and focusing on a select few in a phase gives a
better handle to the engineers and managers in dealing with the complexity of
the problem.
Linear
ordering of activities has some important consequences. First, to clearly
identify the end of a phase and the beginning of the next, some cer- tification
mechanism has to be employed at the end of each phase.
Figure 2.3 The waterfall Model
.
Though the set of documents that should be produced in a project is dependent
on how the process is implemented, the following documents generally form a
reasonable set that should be produced in each project:
–
Requirements document
–
Project plan
–
Design documents (architecture, system, detailed)
–
Test plan and test reports
–
Final code
–
Software manuals (e.g., user, installation, etc.)
2.3.2
Prototyping
Prototyping
is an attractive idea for complicated and large systems for which there is no
manual process or existing system to help determine the requirements. In such
situations, letting the client “play” with the prototype provides invaluable
and intangible inputs that help determine the requirements for the system. It
is also an effective
method of demonstrating the feasibility of a certain approach.
A
development process using throwaway prototyping typically proceeds as follows.The
development of the prototype typically starts when the prelim- inary version of
the requirements specification document has been developed. At this stage, there
is a reasonable understanding of the system and its needs and which needs are
unclear or likely to change.
Figure 2.4 The Prototyping Model
For
prototyping for the purposes of requirement analysis to be feasible, its cost
must be kept low. Consequently, only those features are included in the
prototype that will have a valuable return from the user experience. Excep-
tion handling, recovery, and conformance to some standards and formats are
typically not included in prototypes. In prototyping, as the prototype is to be
discarded, there is no point in implementing those parts of the requirements
that are already well understood. Hence, the focus of the development is to
include those features that are not properly understood.
2.3.3
Iterative Development
The
iterative enhancement model [4] is an example of this approach. In the first
step of this model, a simple initial implementation is done for a subset of the
overall problem. This subset is one that contains some of the key aspects of
the problem that are easy to understand and implement and which form a useful
and usable system.
Each
step consists of removing the next task from the list, designing the
implementation for the selected task, coding and testing the implementation,
performing an analysis of the partial system obtained after this step, and
updat- ing the list as a result of the analysis.
Figure 2.5 The Interative enchanment model.
The
project control list guides the iteration steps and keeps track of all tasks
that must be done.
Though
there are clear benefits of iterative development, particularly in allowing
changing requirements, not having the all-or-nothing risk, etc., there are some
costs associated with iterative development also.
Another
common approach for iterative development is to do the require- ments and the
architecture design in a standard waterfall or prototyping ap- proach, but
deliver the software iteratively.
Figure 2.6 Interative Delivery approach.
The
iterative approach is becoming extremely popular, despite some diffi- culties in using it in this
context. There are a few key reasons for its increasing popularity. First and
foremost, in today’s world clients do not want to invest too much without
seeing returns. In the current business scenario, it is preferable to see
returns continuously of the investment made.
2.3.4
Rational Unified Process
RUP
proposes that development of software be divided into cycles, each cycle
delivering a fully working system. Generally, each cycle is executed as a
separate project whose goal is to deliver some additional capability to an
exist- ing system (built by the previous cycle).
–
Inception phase
–
Elaboration phase
– Construction
phase
–
Transition phase
Each
phase has a distinct purpose, and completion of each phase is a well- defined
milestone in the project with some clearly defined outputs. The purpose of the
inception phase is to establish the goals and scope of the project, and
completion of this phase is the lifecycle objectives milestone.
In
the elaboration phase, the architecture of the system is designed, based on the
detailed requirements analysis. The completion of this phase is the life- cycle
architecture milestone. At the end of this phase, it is expected that most of
the requirements have been identified and specified, and the architecture of the
system has been designed (and specified) in a manner that it addresses the
technical risks identified in the earlier phase.
The
purpose of the transition phase is to move the software from the devel- opment
environment to the client’s environment, where it is to be hosted. This is a
complex task which can require additional testing, conversion of old data for
this software to work, training of personnel, etc.
Figure 2.7 The RUP Model.
RUP
has carefully chosen the phase names so as not to confuse them with the
engineering tasks that are to be done in the project, as in RUP the en-
gineering tasks and phases are separate.
One
key difference
of RUP from other models is that it has separated the phases from the tasks and
allows multiple of these subprocesses to function within a phase. In waterfall
(or waterfall-based iterative model), a phase within a process was linked to a
particular task performed by some process like re- quirements, design, etc. In
RUP these tasks are separated from the stages, and it allows, for example,
during construction, execution of the requirements process.
Though
a subprocess may be active in many phases, as can be expected, the volume of
work or the effort
being spent on the subprocess will vary with phases. For example, it is expected
that a lot more effort
will be spent in the requirement subprocess during elaboration, and less will
be spent in construc- tion, and still less, if any, will be spent in
transition.
Table 2.1 Activity Level of subprocesses in different
phase of RUP
2.3.5
Timeboxing Model
In
the timeboxing model, the basic unit of development is a time box, which is of
fixed duration. Since the duration is fixed, a key factor in selecting the
requirements or features to be built in a time box is what can be fit into the
time box. This is in contrast to regular iterative approaches where the
functionality is selected and then the time to deliver is determined.
Timeboxing changes the perspective of development and makes the schedule a
nonnegotiable and a high-priority commitment.
Having
time-boxed iterations with stages of equal duration and having ded- icated
teams renders itself to pipelining of different
iterations. (Pipelining is a concept from hardware in which different instructions are executed
in paral- lel, with the execution of a new instruction starting once the first
stage of the previous instruction is finished.)
With
a time box of three stages, the project proceeds as follows. When the
requirements team has finished requirements for timebox-1, the requirements are
given to the build team for building the software. The requirements team then
goes on and starts preparing the requirements for timebox-2.
Figure 2.8 Executing the timeboxing process
model.
Contrast this with a
linear execution of iterations, in which the first delivery will be made after 9
weeks, the second after 18 weeks, the third after 27 weeks, and so on.
Figure 2.9 Task of different teams.
Hence, the timeboxing
provides an approach for utilizing additional man- power to reduce the delivery
time. It is well known that with standard methods of executing projects, we
cannot compress the cycle time of a project substan- tially by adding more
manpower.
Timeboxing is well
suited for projects that require a large number of fea- tures to be developed
in a short time around a stable architecture using stable technologies. These
features should be such that there is some flexibility in grouping them for
building a meaningful system in an iteration that provides value to the users.
Agile development
approaches evolved in the 1990s as a reaction to documen- tation and
bureaucracy-based processes, particularly the waterfall approach. Agile
approaches are based on some common principles, some of which are
[www.extremeprogramming.org]:
– Working software
is the key measure of progress in a project.
– For progress in a
project, therefore, software should be developed and deliv- ered rapidly in
small increments.
– Even late changes
in the requirements should be entertained (small-increment model of development
helps in accommodating them).
– Face-to-face
communication is preferred over documentation.
– Continuous
feedback and involvement of customer is necessary for developing good-quality
software.
– Simple design
which evolves and improves with time is a better approach than doing an
elaborate design up front for handling all possible scenarios.
– The delivery
dates are decided by empowered teams of talented individuals (and are not
dictated).
Figure 2.10 Overal process in XP.
The development approach used in
an iteration has some unique practices. First, it envisages that development is
done by pairs of programmers (called pair programming and which we will discuss
further in Chapter 7), instead of individual programmers. Second, it suggests
that for building a code unit, automated unit tests be written first before the
actual code is written, and then the code should be written to pass the tests
Figure 2.11 An Interation in XP.
XP,
and other agile methods, are suitable for situations where the volume and pace
of requirements change is high, and where requirement risks are con- siderable.
Because of its reliance on strong communication between all the team members,
it is effective
when teams are collocated and of modest size, of up to about 20 members.
2.3.7 Using Process
Models in a Project
Suppose a small team of
developers has been entrusted with the task of building a small auction site
for a local university. The university administration is willing to spend some
time at the start to help develop the requirements, but it is expected that
their availability will be limited later.
With these constraints, it is
clear that a waterfall model is not suitable for this project, as the “all or
nothing” risk that it entails is unacceptable due to the inflexible deadline.
The iterative enhancement model where each iteration does a complete waterfall
is also not right as it requires requirements analysis for each iteration, and
the users and clients are not available later.
Consider another example where
the customers are in a highly competitive environment where requirements depend
on what the competition is doing, and delivering functionality regularly is
highly desirable.
For this project, clearly
waterfall is not suitable as requirements are not even known at the start.
Iterative enhancement also may not work as it may not be able to deliver
rapidly.
Tuesday, October 7, 2014
Tugas - Internet of Things
________________________________________________________________
Menurut Gartner, akan ada hampir 26 miliar perangkat di Internet of Things pada tahun 2020 ABI Research memperkirakan bahwa lebih dari 30 miliar perangkat akan terhubung secara nirkabel ke Internet of Things (Internet Segalanya) tahun 2020 Per survei terbaru dan penelitian yang dilakukan oleh Pew Research Internet Project, sebagian besar para ahli teknologi dan terlibat pengguna internet yang menanggapi-83 persen-setuju dengan gagasan bahwa Internet / Cloud of Things, tertanam dan komputasi dpt dipakai (dan sistem dinamis yang sesuai) akan memiliki efek luas dan menguntungkan dengan tahun 2025 ini adalah, dengan demikian, jelas bahwa IOT akan terdiri dari jumlah yang sangat besar perangkat yang terhubung ke Internet.
_________________________________________________________________________________
Integrasi dengan internet menunjukkan bahwa perangkat akan menggunakan alamat IP sebagai identifikasi unik. Namun, karena ruang alamat IPv4 terbatas (yang memungkinkan untuk 4,3 miliar alamat unik), benda-benda di IOT harus menggunakan IPv6 untuk mengakomodasi ruang alamat yang sangat besar dibutuhkan. Obyek di IOT tidak hanya akan perangkat dengan kemampuan sensorik, tetapi juga menyediakan kemampuan aktuasi (misalnya, lampu atau kunci dikendalikan melalui Internet). Untuk sebagian besar, masa depan Internet of Things tidak akan mungkin tanpa dukungan IPv6; dan akibatnya adopsi global IPv6 di tahun-tahun mendatang akan menjadi penting bagi keberhasilan pengembangan IOT di masa depan.
Sifat komputasi tertanam dari banyak perangkat IOT berarti bahwa platform komputasi penerbangan murah kemungkinan akan digunakan. Bahkan, untuk meminimalkan dampak dari perangkat tersebut pada lingkungan dan konsumsi energi, radio daya rendah kemungkinan akan digunakan untuk koneksi ke Internet. Radio berdaya rendah tersebut tidak menggunakan WiFi, atau mapan teknologi Jaringan Selular, dan tetap menjadi daerah penelitian aktif mengembangkan. Namun, IOT tidak akan terdiri hanya dari perangkat embedded, karena perangkat komputasi yang lebih tinggi akan diperlukan untuk melakukan tugas-tugas tugas yang lebih berat (routing, switching, pengolahan data dan sebagainya.). Perusahaan seperti FreeWave Teknologi telah dikembangkan dan diproduksi daya nirkabel rendah radio data (baik tertanam dan mandiri) selama lebih dari 20 tahun untuk memungkinkan mesin-ke-mesin aplikasi untuk internet industri.
_________________________________________________________________________________
Selain kebanyakan area aplikasi baru untuk Internet terhubung otomatisasi untuk memperluas ke, IOT juga diharapkan untuk menghasilkan sejumlah besar data dari berbagai lokasi yang dikumpulkan dan sangat tinggi kecepatan, sehingga meningkatkan kebutuhan untuk indeks yang lebih baik, menyimpan dan mengolah data tersebut .
Beragam aplikasi panggilan untuk skenario penyebaran yang berbeda dan persyaratan, yang biasanya ditangani dalam implementasi proprietary. Namun, sejak IOT terhubung ke Internet, sebagian besar perangkat yang terdiri dari layanan IOT akan perlu untuk beroperasi menggunakan teknologi standar. Badan standardisasi menonjol, seperti IETF, IPSO Alliance dan ETSI, bekerja pada pengembangan protokol, sistem, arsitektur dan kerangka kerja untuk mengaktifkan IOT
Tuesday, December 3, 2013
TIPS Agar Bahan Makanan Tetap Segar
SERINGKALI kita mendapati bahan makanan yang dibeli
saat belanja bulanan sudah tidak segar karena terlalu lama berada di
kulkas dan tidak sempat diolah.
Ternyata ada beberapa hal mudah yang dapat dilakukan agar bahan makanan yang telah dibeli bisa bertahan lama dan tetap segar.1.Ada baiknya kulkas rajin dibersihkan. Dengan begitu bahan makanan yang ada di dalam kulkas akan terjaga kebersihannya dan tidak tercemar bila ada bahan makanan yang sudah membusuk karena terlalu lama berada di kulkas. Bila menemukan bahan makanan yang sudah busuk, bahan makanan tersebut harus segera dibuang agar tidak mengontaminasi bahan makanan lainnya yang masih segar. Pastikan agar tidak ada air atau cairan yang menggenang karena dapat membuat bahan makanan seperti sayur dan buah lebih cepat membusuk
2. Untuk menjauhkan beras dan gandum dari kutu masukkan daun salam dalam kantung berisi beras atau gandum atau tempat penyimpanan lainnya. Daun salam mampu menjaga serangga tetap menjauh dari bahan makanan anda. Ganti daun setiap 3 bulan sekali.
3. Untuk menyerap bau busuk dari bahan makanan atau makanan yang sudah diolah dan dimasukkan ke kulkas, tempatkan belahan kentang di beberapa tempat dalam kulkas. Belahlah kentang menjadi dua bagian atau lebih dan kemudian masukkan secara acak di dalam kulkas. Belahan kentang dapat menyerap bau busuk. Belahan kentang tersebut cukup diganti setiap tiga hari sekali dengan yang masih segar
4. Untuk penyimpanan telur dalam kulkas, simpan dengan ujung yang kecil berada di bawah. Menyimpan dengan cara tersebut akan memastikan bahwa kantung udara yang berada di atas tidak tertekan oleh berat telur sehingga tidak pecah dan pecahnya kantung udara akan mempercepat proses pembusukan telur
5.Simpanlah tomat dan mentimun di tempat yang berbeda karena tomat mengeluarkan gas yang dapat membuat timun menjadi lebih cepat busuk. Ada baiknya tempat penyimpanan tersebut diberikan koran atau kertas sebagai alas agar tomat dan timun selalu kering sehingga lebih awet dan segar
6. Jangan simpan apel bersama dengan buah-buahan matang yang lain karena apel mengeluarkan gas tertentu yang dapat menyebabkan buah-buahan dan sayuran cepat membusuk. Sebaliknya, simpan buah apel dengan buah yang terlalu matang berdekatan agar buah yang belum terlalu matang atau mengkal bisa cepat matang.
7. Masukkan irisan kecil apel atau kentang mentah di dalam wadah tempat menyimpan roti. Tujuannya, agar roti tetap segar lebih lama dari biasanya
Taukah Anda??
Tahukah Anda?
Mulai saat ini silakan Like Fans Page Fakta Unik di Facebook untuk mendapatkan fakta-fakta terbaru setiap hari di Beranda Facebook anda!
25 September 2011
... bahwa tiram dapat berubah kelamin setiap 7 hari namun apabila hal tersebut dilakukan maka beresiko mengganggu psikologinya?
12 September 2011
.... bahwa gigi merupakan satu-satunya bagian tubuh yang tidak dapat memperbaiki dirinya sendiri apabila rusak?
5 September 2011
.... bahwa bola mata burung merak lebih besar daripada ukuran otaknya?
10 Juni 2011
.... bahwa jumlah orang yang berbicara Bahasa Inggris di China lebih banyak daripada jumlah orang yang berbicara Bahasa Inggris di Amerika Serikat?
7 Juni 2011
.... bahwa Gajah Afrika hanya mampu mengangkat beban seberat 25% berat tubuhnya, sedangkan kumbang badak mampu mengangkat beban seberat 850 kali berat tubuhnya. Jadi Kumbang badak lebih kuat daripada Gajah Afrika?
4 Juni 2011
.... bahwa beruang Kutub hanya ada di Kutub Utara sedangkan Penguin hanya ada di Kutub Selatan?
1 Juni 2011
.... bahwa Bunga Mawar yang bewarna MERAH, baru ada semenjak abad ke-20 karena mutasi genetika?
28 Mei 2011
.... bahwa Larry Page dan Sergey Brin(Pendiri Google Inc) memulai usahanya di sebuah Garasi Mobil?
9 Maret 2011
.... bahwa di uang seribuan yang bergambar Kapitan Pattimura pada salah satu kancingnya terdapat smiley tersenyum?
Tugas Desain Web"Cara Membuat Tabel dan menyisipkan Gambar"
Rumus Html di dalam Notepad:
<html>
<head>
<tittle> Desain Web </tittle>
</head>
<body> <BODY BGCOLOR=#AA0000>
<img src="Smile.jpg">
<table border=1>
<tr>
<td align=center colspan=2>Row 1 col 1-2</td>
<td vlign=top rowspan=2>Row 1 col 3</td>
</tr>
<tr>
<td vlign=top rowspan=2>Row 2 col 1</td>
<td>Row 2 col 2</td>
</tr>
<tr>
<td align=center colspan=2>Row 3 col 2-3</td>
</tr>
</body>
</html>
Subscribe to:
Posts (Atom)
