Normalization: An Exercise

ERD to make easier:






Based on the above ERD, we can do process Mapping as follows:





For the normalization process, the need to do is remove the recurrence occurred on the table. Once we do this before the table is already in the form of 1NF





second normal form, table of pegawai increased to 2 table:





Same as in the second normal form, the changes only on the table pegawai only.

Normalization

Normalization, at a high level, is generally defined as the elimination of redundancies from an entity.

Although this is an accurate definition, it does not fully convey the true impact of what normalization is trying to accomplish, and more important, what it means not to apply it to your model.

Before we explain this any further it is necessary to define the five’s forms of normalization. These forms are known as: 1st normal form, 2nd normal form, 3rd normal form, 4th normal form and 5th normal form. Normal form is typically abbreviated “NF.” Each normal form should be dependent on the completion of the previous form, therefore, normalization should be applied in order. Below are the rules that satisfy each normal form:

1st NF: No repeating elements or repeating groups
2nd NF: No partial dependencies on a concatenated key
3rd NF: No dependencies on non-key attributes

Why do normalization :

1. optimalizing of table structures
2. increasing speed
3. eliminating of the same input data
4. more efficient in using storage
5. decreasing redundancy
6. avoid anomaly (insertion anomalies, deletion anomalies, update anomalies).
7. increase data integrity


Functional Dependency

- described connection of attributes in a relation
- an attribute told as functionally dependant inother if we using attribute value for determine another attribute value
- symsbol that used is for deputizing functional dependency that read as functional to determine.
- notation : A -> B

A and B is attribute from a table. its means as functional A determine B or B depended in A, if and as if there are 2 row data with same A value, so B value can be same.
- notation : A-/>B or Ax->B
- it is reverse from previously notation.


First Normal Form - 1NF

A table on the form said to be normal if I did not reside in the unnormalized form of a table, where there is a kind of field multiplication and field that allows a null (empty)
Not the allowed:
-Many attributes of value (Multivalued attributes).
-Attributes composite or a combination of both.

So:

-Price is the domain attribute must be atomic rates


Second Normal Form - 2NF

-Normal form 2NF met in a table if it meets the form of 1NF, and all the attributes than the primary key, have a full Functional Dependency on primary key
-A table does not meet 2NF, if there are attributes(Functional Dependency) are only partial (only depending on the part of the primary key)
-If there are attributes that have no dependence on the primary key, then the attributes must be moved or removed
-Functional dependency X -> Y is full if it is said to delete an attribute A from X means that Y is no longer dependent functional.
-Functional dependency X -> Y said if deleting a partial attribute A from X means that Y is functionally dependent.
-Relation scheme R in the form 2NF if every non-primary key attribute A E R depend on the full primary key fungsioanl R.


Third Normal Form - 3NF

Normal form 3NF fulfilled if the form meets 2NF, and if there are no non-primary key attribute that has a dependence on non-primary key attributes of the other (transitive dependencies).



Boyce-Codd Normal Form (BNCF)

-Boyce-Codd Normal Form constraint has a stronger form of the Normal third. To be BNCF, relations must be in the form of Normal Kesatu and forced each of the attributes depends on the function in the super key attributes.
-In the example below there is a relationship seminar, is the Primary Key NPM + Seminar.

Students may take one or two seminars. Each seminar requires 2 each of the students and led by one of the 2 seminar. Each leader can only take one seminar course. NPM in this example and show a Seminar lecture.


Normal form of the fourth and fifth

-Relations in the fourth normal form (NF 4) if the relation in BCNF and dependency tdak contain many values. To remove the dependency of many values from a relation, we divide the relationship into two new relations. Each relation contains two attributes that have a lot of relationship value.

-Relations in fifth normal form (5NF) deal with the property called the join without any loss of information (lossless join). Fifth normal form (also called the 5 NF PJNF (projection join normal form). The case is very rare and appear difficult to detect in practice.

DATABASE AND ER-Diagram

DEFINITION DATABASE

A set of data stored in the magnetic disk, optical disk or other secondary storage Collection of integrated data-related data of an enterprise (company, government or private) Is a system which consists of collection of the file (table) in a database in a computer system and a related set of data base management program (DBMS:Database Management System) that allows several users and / or other programs for acess and manipulate files ( table-table


DATABASE MANAGEMENT SYSTEM (DBMS)

Collection / database combined with software applications that are based database Application programs are used to access and maintain databases The main purpose DBMS is to provide an environment that is efficient and easy to use, withdrawal and storage of data and information.

ER Model Concepts

-Entities and Attributes

–Entities are specific objects or things in the mini-world that are represented in the database. For example the EMPLOYEE John Smith, the Research DEPARTMENT, the ProductX PROJECT

–Attributes are properties used to describe an entity. For example an EMPLOYEE entity may have a Name, SSN, Address, Sex, BirthDate

–A specific entity will have a value for each of its attributes. For example a specific employee entity may have Name='John Smith', SSN='123456789', Address ='731, Fondren, Houston, TX', Sex='M', BirthDate='09-JAN-55‘

–Each attribute has a value set (or data type) associated with it – e.g. integer, string, subrange, enumerated type, …


Types of Attributes

1.Simple
Each entity has a single atomic value for the attribute. For example, SSN or Sex.

2.Composite
The attribute may be composed of several components. For example, Address (Apt#, House#, Street, City, State, ZipCode, Country) or Name (FirstName, MiddleName, LastName). Composition may form a hierarchy where some components are themselves composite.

3.Multi-valued
An entity may have multiple values for that attribute. For example, Color of a CAR or PreviousDegrees of a STUDENT. Denoted as {Color} or {PreviousDegrees}.

4.In general, composite and multi-valued attributes may be nested arbitrarily to any number of levels although this is rare. For example, PreviousDegrees of a STUDENT is a composite multi-valued attribute denoted by {PreviousDegrees (College, Year, Degree, Field)}.

Entity Types and Key Attributes

1.Entities with the same basic attributes are grouped or typed into an entity type. For example, the EMPLOYEE entity type or the PROJECT entity type.

2.An attribute of an entity type for which each entity must have a unique value is called a key attribute of the entity type. For example, SSN of EMPLOYEE.

3.A key attribute may be composite. For example, VehicleTagNumber is a key of the CAR entity type with components (Number, State).

4.An entity type may have more than one key. For example, the CAR entity type may have two keys:
–VehicleIdentificationNumber (popularly called VIN) and
–VehicleTagNumber (Number, State), also known as license_plate number.


SUMMARY OF ER-DIAGRAM NOTATION FOR ER SCHEMAS




Weak Entity Types

1.An entity that does not have a key attribute

2.A weak entity must participate in an identifying relationship type with an owner or identifying entity type

3.Entities are identified by the combination of:

–A partial key of the weak entity type
–The particular entity they are related to in the identifying entity type

Constraints on Relationships
1.Constraints on Relationship Types
-( Also known as ratio constraints )
- Maximum Cardinality

* One-to-one (1:1)
* One-to-many (1:N) or Many-to-one (N:1)
* Many-to-many

-Minimum Cardinality (also called participation constraint or existence dependency constraints)
* zero (optional participation, not existence-dependent)
* one or more (mandatory, existence-dependent)


Attributes of Relationship types
A relationship type can have attributes; for example, HoursPerWeek of WORKS_ON; its value for each relationship instance describes the number of hours per week that an EMPLOYEE works on a PROJECT.

Structural constraints on relationships:

-Cardinality ratio (of a binary relationship): 1:1, 1:N, N:1, or M:N
SHOWN BY PLACING APPROPRIATE NUMBER ON THE LINK.

-Participation constraint (on each participating entity type): total (called existence dependency) or partial.
SHOWN BY DOUBLE LINING THE LINK

NOTE: These are easy to specify for Binary Relationship Types.

Alternative (min, max) notation for relationship structural constraints:

-Specified on each participation of an entity type E in a relationship type R

-Specifies that each entity e in E participates in at least min and at most max
relationship instances in R

-Default(no constraint): min=0, max=n

-Must have min£max, min³0, max ³1

-Derived from the knowledge of mini-world constraints

Examples:

- A department has exactly one manager and an employee can manage at most one department.
– Specify (0,1) for participation of EMPLOYEE in MANAGES
– Specify (1,1) for participation of DEPARTMENT in MANAGES
- An employee can work for exactly one department but a department can have any number of employees.
– Specify (1,1) for participation of EMPLOYEE in WORKS_FOR
– Specify (0,n) for participation of DEPARTMENT in WORKS_FOR

The (min,max) notation relationship constraints.





Relationships of Higher Degree

- Relationship types of degree 2 are called binary
- Relationship types of degree 3 are called ternary and of degree n are called n-ary
- In general, an n-ary relationship is not equivalent to n binary relationships
- Higher-order relationships discussed further in Chapter 4


Key

- Super Key
A superkey is an attribute or a set of attributes that uniquely identify the relation. That is, no two tuples have the same values on the superkey. By definition, a relation consists of a set of distinct tuples. The set of all attributes in the relation forms a superkey.

- Candidate Key
A key K is a minimal superkey, meaning that any proper subset of K is not a superkey. It is possible that a relation has several keys. In this case, each of the keys is called a candidate key.

- Primary Key
The primary key is one of the candidate keys designated by the database designer. The primary key is often used to identify tuples in a relation.

- Foreign Key
In a relational database, data are related. Tuples in a relation are related and tuples in different relations are related through their common attributes. Informally speaking, the common attributes are foreign keys. The foreign key constraints define the relationships among relations.

- External Key
The external key is a lexical attribute (or compilation lexical attribute) that the values always identify an object instance.

DATA FLOW DIAGRAM

Data flow diagram functions to figure division system into smaller module, making easy user that insufficiently understand computer area for understands system that will be worked. DFD constitutes tool that is utilized on systems developmental methodology which most structure.
A data flow diagram (DFD) shows how data moves through an information system but does not show program logic or processing steps. DFD represent a logical model that shows what the system does, not how it does. That distinction is important because focusing on implementation issues at this point would restrict your search for the most effective system design.
A DFD is a tool that shows how data enters and leaves a particular process. A DFD has four possible components:




PROCESSING SYMBOL

A process receives input data and produces output that has a different content, form, or both. For instance, the process for calculating pay uses two inputs (pay rate and hours worked) to produce one output (total pay). Process can be very simple or quite complex. In a typical company, processes might include calculating sales trends, filling online insurance claims, ordering inventory from a supplier’s system, or verifying e-mail addresses for Web costumers. Processes contain the business logic, also called business rules that transform the data and produce the required results.
The symbol for the process is a rectangle with rounded corners. The name of the process appears inside the rectangle. The process name identifies a specific function and consists of a verb (and an adjective, if necessary) fallowed by a singular noun. Examples of the process are APPLY RENT PAYMENT, CALCULATE COMMISSION, ASSIGN FINAL GRADE, VERIFY ORDER and FILL ORDER.
Processing details are not shown in a DFD. For example, you might have a process named DEPOSIT PAYMENT. The process symbol does not reveal the business logic for the DEPOSIT PAYMENT. To document the logic, you create a process description, which is
explained later in this chapter.
In DFDs, a process appears as a black box, where the inputs, outputs, and general function of the process are known, but the underlying details are not shown. A black box approach shows an information system in a series of increasingly detailed pictures. You use that technique to zoom in and explode each process without confusing the overall view of the system.

DATA FLOW SYMBOL

A data flow is a path for data to move from one path of the information system to another. A data flow in a DFD represents one or more data items. For example, a data flow could represent a single data item (such as student ID number) or it could represent a set of data (such as class roster with student ID number, names and registration dates for a specific class). The diagram does not show the structure and detailed contents of a data flow.
The symbol for a data flow is a line with a single or double arrowhead. The data flow name appears above, below, or alongside the line. A data flow name consists of a singular noun and an adjective, if needed. Examples of data flow names are DEPOSIT, INVOICE PAYMENT, STUDENT GRADE, ORDER and COMMISION. Exceptions to the singular name rule are data flow names, such as GRADING PARAMETERS, where a singular name could mislead you into thinking a singular parameter or singular item of data exists.

DATA STORE SYMBOL

A data store, or a data repository, is used in a DFD to represent a situation in which the system must retain data because one or more processes need to use the stored data at a later time. For instance, instructor needs to store students score on tests and assignments during the semester so they can assign final grades at the end of the term. In a payroll example, you store employee salary and deduction data during the year so you can report total earnings and withholdings at the end of the year.
The physical characteristics of the data store are because you are concerned with a logical model. Also, the length of time that the data is stored is unimportant— it can be a matter of seconds while a transaction is processes or a period of months while data is accumulated for year-end processing. What is important is that a process needs access to the data at some later this time. In DFD, the Gane and Sarson symbol for a data store is a flat
rectangle that is open on the right side and close on the left side. The name of the data store appears between the lines and identifies the data it contains. A data store name is a plural name consisting of a noun and adjectives, if needed. Examples of a data store names are STUDENTS, ACCOUNTS RECEIVABLE, PRODUCTS, DAILY PAYMENTS, PURCHASE ORDER, OUTSTANDING CHECKS, INSURANCE POLICIES, and EMPLOYEES. Exceptions to the plural name rule are collective nouns that represent multiple occurrence of object. For example, GRADEBOOK represents a group of students and their scores.

EXTERNAL ENTITY SYMBOL

An external entity is a person, department, outside organization, or other information that provides data to the system or receives output from the system. The symbol for an entity is a rectangle, which usually is shaded to make it look three-dimensional. The name of the external entity appears inside the square. External entities show the boundaries of the information system and how the information system interacts with the outside world. For
example, a customer submitting an order is an external entity because the customer supplies data to the order system. Other examples of external entities include a patient who supplies medical data, a homeowner who receives a property tax bill, a warehouse that supplies a list of items in stock, and an accounts payable system that receives data from the company’s purchasing system. External entities also are called terminators, because they are data origins or final destinations. Systems analysts call an external entity that supplies data to the system a source, and an external entity that receives data from the system a sink. An external entity name is the singular form of a department, outside organization, other information system, or person. Examples of external entity names are CUSTOMER, STUDENT, EMPLOYEE, MEMBER, SALES REP, WAREHOUSE, INTERNAL REVENUE SERVICE, PAYROLL SYSTEM, and GENERAL LEDGER SYSTEM.

Context Diagrams

During requirements modeling, you used interviews, questionnaires, and other techniques to gather facts about the system, and you learned how the various people, departments, data, and process fit together to support business operations. Now you are ready to create a graphical model of the information system based on your fact-finding results. To learn how to construct DFDs, you will use examples of these information systems. The simplest example is grading system that instructors use to assign final grades based on the scores the students receive during the term. The second example is an order system that a company uses to enter orders and apply payments against a customer’s balance. The third example is a manufacturing system that handles a company’s production. The first step in constructing a set of DFDS is to draw a context diagram. A context diagram is a top-level view of an information system that shoes the system’s boundaries and scope. To draw a context diagram, you start by placing a single process symbol In the center of the page. The symbol represents the entire around the perimeter of the page and use data flows to connect the entities to the central process. You do not show any data stores in a context diagram because data scores are internal to the system. How do you know what external entities and data flows to place in the context diagram? You begin by reviewing the system requirements to identify all external data sources and destinations. During that process, you record the name of the external entities, the name and content of the data flows, and the direction of the data flow. If you do that carefully, and you did a good job of fact-finding in the previous stage, you should have no difficulty drawing the context diagram.

DATA DICTIONARY

A set of DFDs produces a logical model of the system, but the details within those DFDs are documented separately in a data dictionary, which is the second component of structure analysis. A data dictionary, or data repository, is a central storehouse of information about the system’s data. An analyst uses the data dictionary to collect, document, and organize specific facts about the system, including the contents of the data flow, data stores, external entities, and processes. The data dictionary also defines and describes all data elements and meaningful combinations of data elements. A data element, or data item or field, is the smallest piece of data that has meaning within an information system. Examples of the data element are student grade, salary, Social Security number, account balance, and company name. Data elements are combined into records or data flow or retained in a data store. For example, an auto parts store inventory record might include part number, description, supplier code, minimum and maximum stock levels, cost, and list price.

Dictionary’s content Data:

1. Data Current name

Since DD is made bases data current that is adrift at DFD, therefore name of data current shall also be noted at DD, so they what do read DFD and requires more explanation about a given data current at DFD can direct look for it is squashy at DD.

2. Alias

Alias or alias of data gets to be set down if this alias available. Alias needs to be written since same data to have named that variably to person or department one by another.

3. Data Form

Was known that data current can be adrift:

• Of external entity goes to a process, data that is adrift it usually being noted at a document or form;

• Result of a process goes to external entity, data that is adrift it usually exists on write-up media or query is screen look or printed result document computer;

• Result a process goes to process the other, data that is adrift it usually deep shaped variable or needed parameter by its receiver process;

• Result a process that recorded goes to data trove, data that is adrift it usually as a field.
Shaped thus of data that is adrift get as:

• Base document or form
• Printed yielding document computer
• Published reporting
• Variable
• Parameter
• Field

4. Data current

Data current points out where data is adrift and where data will wend. This current information needs to be noted at DD so makes easy to look for current data at DFD.

5. Explanation

For over clarifies again about meaning of noted data current at DD, therefore explanation part can be filled by information about that data current.

BALANCING IN DFD

Data flow that turns in at an issue of one process has to equal data flow that turns in at an issue of details of process on level / level under it. Therefore data flow name that turns in at an issue of one process have with by the name of data flow that turns in at an issue of details of that process and entity’s amount and name external of a process has to equal total and entity’s name external of details of that process.
Things that shall be noticed on DFD who has more than one level:

• Shall available input balance and output among one level and next level
• Balance among level 0 and level 1 is seen on input / output of data flow goes to or of terminal on level 0, meanwhile balance among level 1 and level 2 are seen on input / output of data flow goes to / of process that pertinent
• Data streaming name, storage’s data and terminal on every level shall same if its object with

PROHIBITION IN DFD

Severally prohibition in DFD is as follows:

• Data current may not from external entity directing to wend entity another external without via a process
• Data current may not of direct data trove make towards external entity without via a process
• Data current may not of direct data trove wend another data trove without via a process
• Data current of one process directing to wend another process without via an advisable data trove / one can maybe be avoided

PENGAMATAN AWAL KEBUTUHAN ANALISIS

KONSEP SISTEM INVESTIGASI

Masalah (problem) adalah kesenjangan perbedaaan (gap) antara tujuan sistem dan kondisi sistem yang sebenarnya, dengan pengertian lain kenapa sistem gagal untuk mencapai tujuan sistem yang telah ditentukan sebelumnya.Dengan investigasi, seorang analis akan lebih memahami masalah dan alur sistemnya lebih mendalam, meskipun dalam detect problem sudah diketahui permasalahannya tetapi masih menggambarkan garis besarnya saja.
Banyak laporan dalam deteksi masalah mungkin tidak benar-benar nyata atau tidak dapat dipecahkan. Hal tersebut mungkin dikarenakan :

1.Tujuan terlalu ideal
Tujuan yang terlalu ideal sehingga sulit atau mungkin tidak akan tercapai.

2.Kekurangan sumber daya dan atau sikap
Sistem tidak dapat dikembangkan karena kekuranga sumberdaya, sikap atau keduanya.

3.Pengukuran sistem kurang akurat

4.Tujuan sistem yang sudah ketinggalan
Pernyataan tujuan sistem yang sudah ketinggalan (statement of goals is dated).

5.Perbedaan antara sistem idel dan sistem sementara
Kesenjangan antara sistem yang ideal dan sistem saat ini sifatnya sementara (the gap between the ideal and the current system is temporary and will decrease given patience).

Dalam tahap problem solving, sebaiknya memberikan penjelasan tentang :

1.Penjabaran kondisi sistem yang berjalan melalui kegiatan investigasi secara rinci
2.Mendapatkan konsensus sistem yang ideal.
3.Mengembangkan beberapa alternatif untuk mengurangi perbedaan (gap) antara sistem yang ideal dengan sistem yang sedang berjalan.
4.Memilih alternatif yang terbaik dan menjualnya ke manajemen.

Kendala dalam sistem investigasi

Dalam melakukan investigasi terdapat beberapa hambatan atau kendala yang akan terjadi , diantaranya masalah :

1.Waktu (time)
Analis kekurangan sumber daya (resource) waktu, sehingga hanya melakukan sebagian kegiatan investigasi. Biasanya waktu berhubungan dengan masalah biaya yang dibutuhkan.
2.Biaya (cost)
Seringkali biaya yang dikeluarkan berhubungan dengan lamanya waktu untuk kegiatan investigas, sehingga manajemen akan memberikan batasan biaya
3.Ilmu pengetahuan (knowledge)
Manager sistem informasi cenderung menyuruh analis yunior yang belum memiliki keahlian teknis atau pengetahuan yang cukup, sehingga akan
berdampak pada hasil investigasi yang kurang mendalam,matang atau lengkap.
4.Politik (politics)
Manajemen atau pihak-pihak tertentu mungkin menyebarkan isu-isu yang tujuannya untuk menghambat kegiatan investigasi.
5.Campur tangan (interference)
Adalah terdapatnya pihak-pihak yang berusaha campur tangan atau mengatur dalam kegiatan investigas sehingga akan menganggu atau menimbulkan kekacauan.

Rekomendasi
Hasil dari investigasi adalah sebuah rekomendasi, yang salah satunya adalah
sebagai berikut :

1.Tidak mengambil tindakan apapun karena tidak ditemukan masalah.
Hal tersebut dapat terjadi karena mungkin dalam preliminary report, masalahnya dibuat-buat sehingga pada saat dilakukan investigasi masalah- masalahnya tersebut tidak terjadi atau tidak ditemukan.

2.Melakukan pemeliharaan sistem untuk masalah-masalah yang kecil.
Pemeliharaan sistem yang dilakukan setiap hari (periode pendek) akan membantu meminimalkan masalah-masalah yang muncul sehingga cepat untuk ditangani dan selalu terkontrol secara baik.
3. Meningkatkan kemampuan atau ketrampilan pemakai didalam menjalankan atau menggunakan sistem informasi.
4.Mempertimbangkan untuk modifikasi sistem secara total, sehingga perlu pemikiran untuk menggantinya dengan sistem yang baru.
5.Menempatkan masalah yang terjadi kedalam rencana pengembangan sistem yang segera dilakukan.

Taktik investigasi

1.Dengarkan, jangan mengurui (listen, do not lecture).
Jika anda tahu semua jawaban, pasti anda tidak akan melakukan investigasi. Sehingga dalam kegiatan investigasi sebaiknya memberikan waktu yang cukup bagi pihak manajemen atau pemakai untuk menjelaskan secara lengkap dan jelas dan analis sistem jangan terlalu mendominasi pembicaraan.

2.Jangan memberikan pemecahan awal terhadap masalah (do not presolve the problem).
Artinya jangan berusaha menunjukkan pemikiran untuk memecahkan masalah, sebelum seluruh kegiatan investigasi selesai dilakukan, sehingga menghindarisolusi-solusi yang sebagian-sebagian.

3.Membandingkan cerita (compare stories).
Berbeda orang berarti berbeda pandangan terhadap masalah yang sama,sehingga perlu melibatkan supervisor dan bawahan dalam memberikan pandangan masalah secara jelas dan dapat dipercaya. Sebaiknya tidak mendengarkan dari 1 sumber sehingga hanya ada 1 pandangan (opionio). Ketika pemakai memiliki perbedaan pandangan, sebaiknya cari perbedaannya dan kemudian mencari pandangan yang memiliki kesamaan.

4.Perhatikan keengganan tanggapan (look for reluctant responses).
Keengganan memberikan tanggapan mengindikasikan sesuatu yang disembunyikan.
Terlalu banyak masalah sistem dapt juga menyebabkan kebingungan sehingga tidak mampu menjelaskan secara lengkap.

5.Perhatikan masalah inkonsistensi logikal (probe for logical inconsistencies).
Inkonsistensi logikal adalah penghentian flow data dimana data tersebut hilang, atau secara tiba-tiba muncul data tertentu. Beberapa hal yang berhubungan dengan masalah ini :
*Ada data masukkannya tetapi tidak ada outputnya (black hole).
*Ada keluaran (output) tetapi tidak ada data masukannya (miracles).

6.Perhatikan dampak anda (observe your effect).
Memperhatikan perbedaan dari pemakai ketika anda hadir dan saat anda tidak hadir. Penilaian secara langsung disebut dengan internal probe. Sedangkan external probe adalah penilaian yang dilakukan tanpa diketahui oleh siapapun (searching external material), seperti dengan menganalisa laporan, sejarah permasalah terdahulu, dan sumber-sumber investigasi sekunder lainnya.

7.Memerlukan kerja keras, sehingga menimbulkan kebosanan (expect hard, boring work).
Jadilah detektif yang profesional dan sabarlah dalam menangani permasalahan sistem secara bertahap.dan berkesinambungan.

8.Hindari masalah politk (avoid politics).
Misi analis sistem adalah fakta bukan mengadili (your mission is fact, notjudgement).

Teknik investigasi

Teknik investigasi meliputi kegiatan :

Secara langsung (direct (internal) probes):

Yaitu untuk mengetahui secara langsung apa yang terjadi dalam lingkungan pemakai. Mereka mengijinkan anda untuk memperhatikannya langsung tanpa melalui pihak-pihak tertentu (interpreter). Internal probes merupakan sumber kekacauan (disruptive), karena timbul perbedaan sikap. Internal probes digunakan sebagai pengkayaan (a richer) dan kelompok pembenar dari fakta yang terjadi (truer group of facts). Terdapat tiga teknik untuk melakukan investigasi langsung, yaitu dengan :

* Kuesioner (questionnaires).
Teknik ini sangat tepat, apabila dalam investigasi memiliki kendala waktu dan biaya. Meskipun mendapatkannya dari responde melalui blangko isian. Adapun hal-hal dalam kuesioner kondisi akan penjelasannya akan berbeda apabila dilakukan tatap muka langsung (face to face interview). Hal terbaik dari kuesioner adalah sebagai dokumen yang dapat menunjukkan perbedaan-perbedaan yang terjadi pada responden.
* Tanya jawab (interview).
Kegiatan ini membutuhkan waktu dan keahlian khusus. Tidak semua orang dapat melakukan tanya jawab dengan sukses. Interview dapat digunakan untuk pertanyaan yang berurutan secara mendalam disamping lebih fleksibel sesuai dengan kondisi lapangan. Kendala yang dihadapi adalah waktu dan keahlian khusus.

* Pengamatan (observation).
Merupakan internal probe yang kuat (a powerful internal probe). Duduk bersama dengan pemakai sistem dengan melakukan pengamatan dengan pertanyaan yang lebih spesifik. Mengapa anda melakukan kegiatan ini ? atau dimana dokumen ini akan dipindahkan ?. Setiap pertanyaan mungkin akan dapat menunjukkan pemecahan masalah misterius.

Secara tidak langsung (indirect (external) probes)

Kegiatan yang dapat dilakukan dengan cepat dan tidak kelihatan dari operasional personel, sehingga dapat mengetahui sisi luar atau sesuatu yang disembunyikan dari komunitas pemakai. Kegiatan ini akan mendominasi pada awal kegiatan SDLC, selanjutnya internal probe untuk memperdalam.

* Aliran prosedur (procedure flow).
Prosedure operasional merupakan sarana (vehicles) bagi pegawai baru mengerti pekerjaannya dan pengalaman karyawan untuk menangani masalah. Jika procedure flow tidak benar, sistem informasi tidak dapat dioperasikan secara benar pula. Gunakan system flowchart untuk menelusuri jalannya informasi sebagai penjelasan prosedure operasinya. Apabila ada permasalahan diprosedur, masalah tersebut mungkin akan timbul dalam operasional yang sebenarnya.

* Mempelajari dokumen (document review).
Adalah dengan mendapatkan dan mengumpulkan dokumen-dokumen penting (critical document). Jika masalah banyak terjadi di customer orders, kumpulkan sumber dokumen asli dari customer orders tersebut yang digunakan sebagai data entry-nya, format interaktif layar, detail transaksi, ringkasan dan kesalahan laporan yang terjadi. Dokumen seringkali menjadi penyebab masalah.

* Sampel (sampling).
Mungkin anda membutuhkan informasi dari para vendor billing yang telah memberikan diskon pada saat pembayran, karena perusahaan kehilangan uang saat diskon tidak diberikan ketika terjadi penundaan pembayaran. Anda dapat melibatkan para pelanggan pembayar untuk mendapatkan informasi (walaupun ada banyak transaksi). Akhirnya anda dapat membuat daftar sampel data dengan pemilihan random untuk satu minggu terakhir, memilih 20 halaman dari transaksi harian, memilih 5 item dari setiap halaman yang terpilih., merekam informasi untuk setiap 5 item dan menghitung rata-raa dan varian untuk sampel-sampel dari semua transaksi pembayaran yang terjadi.

* Tabular (Tabular tools)
Disebut juga matrix, yaitu daftar cek (checklists) untuk menemukan perselisihan (discrepancies) dalam alur transaksi.
Deskripsi sistem saat ini
Menentukan kinerja sistem saat ini akan mengalami kesulitan apabila perusahaan tidak memiliki sebuah standar pengukuran kinerja sistem. Sayang sekali, perusahaan cenderung tidak memperbarui (to update) dokumentasi sistem yang berjalan. Karenanya, analis memperbaiki dokumen selama investigasi masalah sistem.
Deskripsi sistem saat ini meliputi penjelasan :
a. Masukan (inputs)
b. Keluaran (outputs)
c. File (files)
d. Elemen data (data elements)
e. Volume transaksi dan dokumen tindakan (transaction and action document
volume)
f. Diagram aliran data (data flow diagrams)


KEBUTUHAN ANALISIS

Tahap interaksi intensif antara analis sistem dengan end user dimana tim pengembangan sistem menunjukkan keahliannya untuk mendapatkan tanggapan dan kepercayaan pemakai sehingga mendapat partisipasi yang baik.


TUJUAN YANG INGIN DICAPAI:

1.Menjelaskan sistem secara lengkap
2.Menggambarkan sistem informasi yang ideal
3.Membawa sistem informasi yang ideal ke kondisi saat ini dengan memperhatikan kendala sumber daya
4.Memberikan dorongan terhadap keyakinan pemakai ke dalam pengembangan sistem


Metode

1.Tanya Jawab
2.Kuisioner
3.Observasi
4.Prosedur analisis
5.Pengamatan dokumen

KENDALA SUMBER DAYA

1.Waktu
2.Uang
3.Keahlian
4.Teknologi
5.Faktor Eksternal

Dokumen kebutuhan analisis

1.Arahan analisis :
Hubungan dengan pemakai akhir, pengamatan proses, permasalahan dalam pengumpulan data
2.Kebutuhan Pemakai :
Kebutuhan sebenarnya, Kebutuhan laporan, kebutuhan pelatihan dan pengaruh sistem baru
3.Kendala Sistem :
Menjelaskan kendala waktu dan biaya, keahlian, teknologi dan faktor eksternal
4.Dokumen berupa instrumen pengumpulan data, konsensus statistik, aliran data secara logikal dan phisik, elemen data awal dalam kamus data.

GENERATING SYSTEMS ALTERNATIVES

Mendekatkan kondisi sistem saat ini dengan kondisi sistem yang ideal?
1.Membuat alternatif untuk memecahkan masalah sistem informasi
2.Alternatif terbaik tersebut diterapkan secara bijaksana


Pilihan Strategi

Distributed versus centralized processing
Perubahan keputusan informasi dari centralized data processing ke decentralized end user responsibility center:
Integrated versus dispersed database
Perancang sistem harus mempertimbangkan data apa saja yang masuk dalam data base dan yang masuk ke dalam File:
Surround Strategy of System Development
Lingkungan sekitar strategi penting dalam hal pengambilalihan perusahaan karena sistem informasi dari perusahaan lain mungkin berbeda dengan perusahaan saat ini.

Pilihan Taktik
Dilakukan sebelum pilihan perancangan operasional
Pilihan Perancangan Operasional
Pilihan perancangan dapat dikelompokkan kedalam:

1.Input

Online Vs Off Line Data Entry
Keyed Vs Machine Readable Data Entry
Centralized Vs Decentralized Data Entry

2.Processing

Batch Vs Realtime record update
Sequential Vs Direct Access to records
Single Vs Multiple User update of records

3.Output

Traditional Vs Turn Around Documents
Structured Vs Inquiry based reports

Taktik membandingkan : Sistem dibandingkan berdasarkan biaya dan keuntungan secara relatif.

Ada 3 cara sistem A dikatakan lebih unggul dengan sistem lainnya jika:
1.A mempunyai biaya lebih rendah dari B dan keuntungan keduanya sama
2.A mempunyai biaya lebih rendah dari B dan A menghasilkan keuntungan yang lebih banyak dari B
3.A dan B mempunyai biaya sama namun keuntungan yang dihasilkan A lebih banyak.

Beberapa Metode Komparasi Sistem

1.Break Even point Analyisis
2.Payback Period
3.Discounted PayBack period
4.Internal Rate of Return

Kategori Biaya

1.Hardware
2.Software
3.People
4.Suppliers
5.Telecommunications
6.Physical sites

Perincian Biaya

Membandingkan biaya sistem informasi melalui kehidupan sistem, analis memproyeksi berapa perubahan biaya untuk masa depan dan ada 3 model biaya sistem informasi yaitu Linear, Eksponensial dan Step Function.
1.Biaya sistem informasi dapat terjadi sekali saja dan dapat pula terjadi secara berkesinambungan.
2.Biaya sistem informasi yang terjadi sekali saja yaitu ontime cost dan development cost yang terjadi saat pengembangan sistem.
3.Biaya sistem informasi yang terjadi secara terus menerus diantaranya adalah reccuring cost serta operational cost dimana biaya ini terjadi saat sistem informasi beroperasi setiap hari.

FAKTOR SISTEM INFORMASI
Faktor Kualitatif yang mengarah kinerja sistem informasi yang baik diantaranya
1.Mengurangi tingkat kesalahan
2.Mengurangi waktu untuk memperbaiki kesalahan
3.Mengurangi waktu tanggap dari workstation alternatif
4.Mempercepat waktu penyediaan informasi
5.Meningkatkan keamanan sistem
6.Memperbanyak update sumber record aktif
7.Meningkatkan kepuasan pemakai


FAKTOR STRATEGI PERUSAHAAN

1.Kepuasan konsumen
2.Tingkat penjualan meningkat
3.Komitmen konsumen dan vendor
4.Informasi pemasaran produk

MEMPRESENTASIKAN PEMBELAJARAN SISTEM
1.Melakukan presentasi secara singkat
2.Mengurangi penjelasan teknik secara detail
3.Mempretasikan secara jelas dengan alat bantu visual
4.Jika menggunakan model gunakan alat bantu misalnya laptop sehingga lebih informatif
5.Tekankan keuntungan dari usulan sistem informasi dengan beberapa alternatif yang ada sesuai kondisi yang dialami perusahaan.

KEPUTUSAN MELANJUTKAN ATAU TIDAK

1.Jika perusahaan memutuskan untuk mengembangkan sistem maka departemen informasi akan melakukan proses selanjutnya yaitu Proses Desain Sistem.
2.Jika sebaliknya maka System Development Life Cycle (SDLC) akan dihentikan.
3.Sering kali akan ditemukan masalah dengan sistem studi dan dan biasanya top management akan meminta dilakukannya pengerjaan ulang terhadap sistem studi.
4.Model akan menjelaskan beberapa bagian tahapan yang diulang dan kadang-kadang departemen informasi akan membuat keputusan mengulang tahapan sebelum menjelaskan sistem studi.
5.Dengan alternatif, keputusan untuk mengulang sebuah tahapan SDLC sebelumnya atau tidak disebut Go – No –Go Decision.

SYSTEM DEVELOPMENT

SYSTEM DEVELOPMENT


SYSTEM
- A set of components that interact with each other to form as a whole.
- Work together toward achieving a common goal
ATTRIBUTE
- Contains qualities and capabilities not found in the individual elements.

Components of a System
1. Input - anything that enters the system.
2. Output – anything that leaves the system goal or purpose for which the system exists.
3. Process – transforms input into output.
4. Feedback – reintroduces a portion of the output of a system as an input into the same system.

Elements of a System
1. Purpose – the reason it exists.
2. The reference point for measuring its success
3. Subsystems - parts or elements which perform specified tasks that are compatible with the goals of the larger system of which these are parts.
4. Environment – the people, facilities, rules, policies, and regulations that surround a system.
5. Boundary – the perimeter or line of demarcation between a system and the
environment.
6. Connections – transmit the flow of material and information that coordinate the system’s components.

Systems Concept
- Business System
A collection of policies, procedures, methods, people, machines, and other elements that interact and enable the organization to achieve its goals.
- Information System
A collection of procedures, programs, equipment, and methods that process data and make it available to management for decision-making.


Components of Information System.
- Work practices – methods and procedures used by people and technology to perform work.
- Information – can include formatted data, text, images and sounds.
- People – people who enter, process and use data.


Reasons for the need of an Information Sistem.
- Growing size of the organization and the no. of competitors.
- Growing ability of computers to process large amount of data with great speed.
- Dramatic increase in volumes of data generated.
- Advances in communication technologies to permit faster data communication
- Much more sophisticated technology today


Characteristics of Information Systems
An analyst learns about an information system by asking questions about the system and how it supports business operations. As a systems analyst, you might ask the following questions as you complete your work:

1. Does this system interact with other system?
For examples, a purchasing system generates orders that become input for a production system. Each system interacts with a finance system that monitors the company’s profitability. A breakdown in any one system can affect companies rely on telecommunications and the Internet for mission-critical systems.
A company’s information system also can interface with a system operated by another firm, such as when a payment is made by one company’s accounts payable system to another company’s accounts receivable system. This process, known as electronic data interchange (EDI), involves the computer-to-computer transfer of data between companies. EDI has
expanded rapidly as companies form closer working relationships with their suppliers and customers. In the past, EDI was used mainly for processing transactions between two companies, such as purchasing or payments. Toda, EDI can help a firm plan its production, adjust inventory levels, or stock up on raw materials using data that comes from another company’s information systems.

2. What are the system’s boundaries? A system boundary indicates where one system ends and another system begins. The boundary between two systems is not always clear-cut. For example, when are customer payments part of the accounts receivable system, and when
are they included in the finance system? If customer payments need to be adjusted, must the adjustments take place in both systems? Who makes the adjustments? What processes and files are involved? Complex systems have many interfaces with other systems; the
system analyst must carefully plan and design theses systems to design their boundaries correctly.

3. Will the system handle specialized business needs? Many firms require specialized systems for information management that is unique to their company or industry. At a college, for example, specialized systems handle class registration, classroom scheduling, and student grading. At a hospital, specialized systems manage patient admissions, room scheduling, and insurance billing. Firms in the banking, insurance, airlines, and telecommunications industries require complex systems to run their businesses. If a specialized system is available as a vertical software package, a company can purchase and
customize the package. Otherwise, a company must develop specialized in-house systems.

4. What size is the company, and what growth is forecast? Large and small companies in the same industry have different information systems requirements. For example, banks range in size from local operations with one or two branches to multinational banks with branches in many states and foreign countries. All banks handle loan processing and checking accounts. A multinational bank, however, has a much higher volume of customers, transactions, and accounts. A large bank’s systems are more complex because they consolidate information from banking centers around the world, handle currency exchange issues, and offer a wide array of products and services.


Who develops Information Systems?
Traditionally, a company either developed its own information systems, called in house applications, or purchased systems called software packages from outside vendors. Today, the choice is much more complex. Options include Internet-based application services, outsourcing, custom solutions from IT consultants, and enterprise-wide software strategies.
Regardless of the development method, launching a new information system involves risks as well as benefits. The greatest risk occurs when a company tries to decide how the system will be implemented before determining what the system is supposed to do. Instead of putting the cart before the horse, a company must begin by outlining its business needs and identifying possible IT solutions. Typically, this important work is performed by systems analysts and other IT professionals. A firm should not consider implementation options until it has a clear set of objectives. Later onas the system is developed, a system analyst’s role will vary depending on the implementation option selected.


The Purpose or Goal of Developing an Information System

1. To Solve a Problem
2. To Get Opportunities
3. To Complete the Instruction


The Organization Expectations after Implementing an Information System

1. Performance

Performance of the new system are effective. Performance can be measure from throughput and response time. Throughput it means amount from activity can do at mean time. Respond time are average delayed of time between two transaction or activity add with time to respond that activity.

2. Information

Increase quality of information can make the organization growth well. This is like our company have update information about accountancy. If our company want to improve the quality of information, we must discover a lot of resource and publish it. So good of information that we have, it will increase our growth organization.

3. Economy

In aspect economy it mean benefit from profit we have or reduction of cost used for our organization. In organization always had a profit from selling the product and always had a excreation of organization like salary of employee, pay electricity and any others thing. So economy of organization depend of benefit from organization profit and reduction of cost used for organization.

4. Control

In our organization need to control the detect and fix the problems. It mean after we development the new system we must control every time, we check our system are work so well or not. If our system not work like our plan, we mus find the problem and solve it. Good system came from good control of the system and can solve the problems.

5. Efficiency

Efficiency need in organization because it can make organization useless of resource like if our organization work in accountancy. In old system we must pay an accountant to work in our organization for one job. If our organization had a much job we must pay much accountant to. If we use new system work in computer, we just need a administrator and user to input the data. So if we use new system we can efficiency the cost for pay accountant. Efficiency can measure from output devide by the input.

6. Services

Services in this aspect mean increase about services give from the system. So system have services to support our ourganization like system work fast and precise calculation.



SYSTEM DEVELOPMENT LIFE CYCLE

• Organization use a standard set of steps, called system development methodology, to develop and support their information systems.
• Like many process, the development of information system often follows a life cycle. created – tested – introduced to the market. Its sales increase, peak, and decline.
• Finally, the product is removed from the market and replaced by something else.


SDLC marks the phases or steps of information system development as show in a figure below. The specific steps and their sequences are meant to be adapted as required for a project.

Spiral approach of system development
• The circular nature of the life cycle diagram illustrates how the end of the useful life of one system leads to the beginning of another project that will replace the existing system altogether.
• This concept is clearly brought out with the diagram shown next. Each of these phase has specific outcomes and deliverables that feed important information to other phases. At the end of each phase, the systems development reaches a mile stone.




Waterfall Model




 SDLC used in an Organization is an orderly set of activities conducted for each development project
 In SDLC each phase has specific outcomes and deliverables that feed important information to other phases. At the end of each phase, a system development project reaches a mile stone.


Iterative Model



Iteratif Model here same with waterfall model, here found same processes, like requirement, design, implementation, and testing (verification).


Phases of the Systems Development Life Cycle




• Systems Planning and Selection
– Two Main Activities
• Identification of need
• Investigation and determination of scope
• Systems Analysis
– Study of current procedures and information systems
• Determine requirements
• Generate alternative designs
• Compare alternatives
• Recommend best alternative
• System Design
– Logical Design
• Not tied to any specific hardware /sys.sw platform
• Concentrates on business aspects of the system
– Physical Design
• Technical specifications
• Decides which programming languages to be used
• Decides which HW platform, which OS to be used
• The final product of the design phase is presented in a form such as diagram or written report ready to turned over to programmers and other system builders for construction.

• Systems Implementation and Operation
– Implementation
• Hardware and software installation
• Programming
• testing
• User Training
• Documentation
– Operation
• System changed to reflect changing conditions
• System obsolescence

Detailed Notes on SDLC
1. System planning and selection Phase:
• This phase has two important activities.
– The first activity involves in identifying the need for a new or enhanced system. Information needs of the organization are examined and system to meet these needs are identified. Then the Analyst evaluates priorities and brings out the needs into a written plan.
•
– During this phase, based on the feasibility study, the management determines whether to take up the systems development.
• Once decided to take up, a specific plan will be produced for the proposed project. The plan specifies the time and resources needed for its execution of the project.

Preliminary Investigation.



- Preliminary Investigation includes:
- Define the problem
- Suggest alternative systems
- Prepare a short report


2. System Analysis Phase:
Analysis expands the Strategy Stage into details that ensure business consistency
and accuracy. The Barker analysis stage is designed to capture all of the business processes that need to be incorporated into the project. Barker divides Analysis into two components: Information Gathering and Requirements Analysis. Information Gathering: includes the building of more detailed ERD called an Analysis ERD (equivalent to what I called a logical model), process and data flows, a requirements document, and an analysis evaluation. This step also includes an analysis of the existing legacy systems.
Much of the information gathering is accomplished via interviews with users. As discussed in the next chapter this is accomplished by understanding the user interface and determining whether to do individual and/or group analysis techniques. Requirements Analysis: Once the information gathering is complete a detailed requirements analysis or specification documents must be produced. It contains the relevant tools as outlined in my analysis document, namely, the detailed PFDs, DFDs, ERDs and Process Specifications. In the Barker approach the requirements document may also include audit and control needs, backup and recovery procedures, and
first-level database sizing (space needs).
• In this phase, the systems analyst understands the organizations existing procedures and then suggest an information system as solution. This Analysis phase has several sub phases,
– Involves determining the requirements of the system. System analyst work with the users to determine what the users want from the proposed system.
– Study the requirements and structure them.
– Generate alternative information system based solutions
– Compare these alternatives to determine which is best in satisfying the requirement – considering the cost, labour and technical levels the organization is willing to commit.
– Select a solution.


Six-phase problem-solving procedure for examining and improving an information system:







Analysis tasks include:
- Gathering data
- Analyzing the data
- Document systems analysis




Analyzing the Data
- Checklist
- Top-down analysis method
- Grid charts
- Decision tables
- System flowcharts
- Data flow diagrams
- Automated design tools -CASE


Grid chart




Decision table




Data flow diagram




System flowchart





The analysis phase of the systems development life cycle (SDLC) begins with the creation of information-gathering channels. Such channels include documentation, interviews, observation, questionnaires, and measuring. Documentation can help establish what the old system does and how it works. Interviews are a great way to gather information because you can find out exactly what makes an end-user happy. Observation can add insight and out-of-the-box thinking to the mix. Questionnaires are great for collecting information from many people. Measuring is important because you will need to measure things like how much space the new system will take up or how many inputs/outputs will be needed. At this point, all requirements for the creation of the system should be noted.
Once the gathered information from the channels is analyzed, it is put into visual diagrams which include flow block diagrams, organizational charts, task templates, flowcharts, data flow diagrams, entity relationship diagrams, and state-transition diagrams. The most common diagram is a data flow diagram like this:




3. System Design Phase:
The Design Stage consists of the incorporation of physical appearances and other requirements that are specific to actual products, for example, coding and naming conventions. The typical design needs are screen layouts, navigation tools (menus, buttons, etc.) and help systems. The Design Stage must also ultimately achieve the agreed upon performance or service levels.
The ERD will be transformed to a physical database design. Detail specifications will be translated into program modules, and manual procedures to operate the system should be documented. In terms of screens, reports, and “bridges” that
connect modules, various prototype designs can be incorporated to show users how the navigation and physical “look and feel” will occur during the user interface. As previously discussed, Design is not a step that occurs without iteration.
The Design Stage often iterates with analysis, where questions and suggestions from designers can raise issues about alternatives not considered during the analysis stage What is critical about this design method is its interactive yet interdependence with non-application components such as network design, audit and control, backup and recovery design, data conversion, and system test planning.

• During design phase the recommended solution is converted into logical and then physical system specifications. The designing team will design all aspects of the system such as input & output screens, reports, databases and computer processes.
• Logical design is not tied to any specific hardware and systems software platform. Conceptually, the system design could be implemented on any hardware and system software. Logical design concentrates on the business aspects of the system, that is how the system will impact the functional units with in the organization.
• As the next stage, the logical design will be converted into physical design. The team will design the various parts of the system to perform physical operations necessary to facilitate data capture, processing and information output. Then during this part, the analyst decides on the programming languages and database system, hardware platforms, and network environment. The final product of the design phase is the physical system specification, presented in a form such as diagram or written report, ready to be turned over to programmers for construction.
Design includes 3 major tasks:
1. Designing alternative systems
- Economic feasibility
- Technical feasibility
- Operational feasibility
2. Selecting the best system
3. Writing the systems design report




Once the analysis phase is complete and all requirements are established, it is time to record a rough draft of the system logic to be used for development. This is the design phase of the systems development life cycle (SDLC). The goal of the design phase is to generate system specifications. These system specifications satisfy requirements set earlier in the SDLC. They are presented as high level vs. detail and logical vs. physical.
There are several design strategies that can be used. Such strategies include outsourcing (both domestic and overseas), buying off-the-shelf, building in-house, or a combination of the three. In addition to the design strategies, special techniques are used. They are process modeling, data modeling, data modeling, computer-aided software engineering (CASE), and object-oriented design (OOD).
CASE tools represent software that allows for strategic creation of logic. An example of a CASE tool is Microsoft Visio. This CASE tool creates data flow diagrams and flowcharts to illustrate the logic of a system. This is a great way to demonstrate the specifications of a system and achieve the goal outcome of the design phase. Here is an example of a flowchart:




4. Implementation Phase:
• Implementation and operation Phase, is the final phase and it involves, implementation and operation.
• During this phase system specifications are turned out to a working system, tested and put into use.
• Implementation includes coding, testing and installation.
– During coding, programmers write the programs that make up the system.
– During testing, programmers and analysts test individual programs and the entire system in order to find and correct errors.
– During installation, the new system becomes a part of the daily activities of the organization. System implementation activities also include initial user support such as the finalization of documentation, training programs and ongoing user assistance.
• Once the system has been installed, the analyst team establishes a support plan. This is second part of the fourth phase of the SDLC is operation.
– After installation, users sometime find problems with systems and often request for improvements.
– During operation, programmers make changes that users ask for and modify the system to reflect changing business conditions. These changes are necessary to keep the system running and useful. The amount of time and effort devoted to system enhancements during operation depends a great deal on the performance of the previous phases of the life cycle.
• After few years, when the business environment changes, the system is no longer performing as desired, and the costs of keeping a system running become prohibitive, the systems will need a total change over. These problems indicate that it is time to begin designing the system’s requirement, there by completing the loop and starting the life cycle over again.
New system is installed and people are trained to use it:
Types of conversion
- Direct
- Parallel
- Pilot
- Phased
- Training




ApproachSystem Development

Found several approach to develop system, that is:
1. Classical approach vs structured approach (looked at from methodology that used).
2. Piecemeal approach vs system approach (looked at from target that be achieved)
3. Bottom-Up approach vs Top-Down approach (looked at from manner determines need fromsystem).
4. Total-system approach vs modular approach (looked at from manner develop it).
5. Great loop approach vs evolutionary approach (looked at from technology that used).

1. Classical Approach Vs Structured Approach

Classical Approach

Classical approach is approach insides system development that follow stages at system life
cycle without supplied with tools and techniques.
Troubleshoots that can emerge from approach classic, that is:

1. Software development will be difficult.
Classical approach less give tools and techniques insides develop system and as finally software development process becoming not directional and difficult to done by programmer.

2. Treatment cost or system maintenance will be more expensive.
The expensive treatment cost at classical approach caused system documentation that developed less complete and less structured.

3. Big error possibility system.
System not test during the development stage is principal source from system errors. Classical approach doesn't prepare to manner systems analysis to do testing system, so that system errors possibility will be bigger.

4. System success less well guaranted.
Emphasis from classical approach work from system developers staffs, not in system user. Because classical approach less involve system user in system development, so system user needs are less matching with the one which desirable and as finally system that applied less success.

5. System applications internal issue.
Because system user involvement under communication in system development stage, so only will know only in stage will applied. As finally system user will be startled and unaccustomed with bew system suddenly introduced.

Structured Approach
Structured approach equiped with tools and techniques that wanted in system development, so that end result from system that developed be got system the structure will be defined well and clear.

2. Piecemeal Approach Vs System Approach

Piecemeal approach
Piecemeal approach be to system approach development that emphasized at one particular activity or certain application. Activity that chosen, developed regardless of the position at information system or regardless of overall target from organization.

System approach
System approach pays information system as one integration unitary to each activity or the application. This approach also emphasized in overall goal achievement from organization, not only in that information target.


SYSTEMS DEVELOPMENT TECHNIQUES AND TOOLS.

In addition to understanding business operations, systems analysts must know how to use a variety of techniques, such as modeling, prototyping, and computer-aided systems engineering (CASE) tools, to plan, design, and implement information systems. They must be able to work in team environments where input from users, managers, and IT staff is synthesized into a design that will meet everyone’s needs. And they must be able to use
other software tools to illustrate accurately their designs and ideas.

1. Modeling
Modeling produces a graphical representation of a concept or process that systems developers can analyze the, test, and modify. A system analyst can describe and simplify an information system by using a set of business, data object, network, and process models. A business model, or requirements model, describes business functions that an information system must support. A data model describes data structures and design. An object model portrays the design and protocols of telecommunications links. A process model describes system logic and process that programmers use to develop necessary code modules. Although the models might appear to overlap, they actually work together to describe the same environment from different points of view. Modeling involves various techniques, such as data flow diagrams, entity-relationship diagrams, use cases, and unified modeling language. Those techniques are described in more detail in next Chapter.

2. Prototyping
Prototyping involves the creation of an early working version of the information system or its components. Just as an aircraft manufacturer tests a new design in a wind tunnel, systems analysts construct and review prototypes for a larger systems. Prototyping tests system concepts and provides an opportunity to examine input, output, and user interfaces before final decisions are made. The prototype can serve as an initial model that is used as a benchmark to evaluate the completed system, or the prototype itself can develop into the final version of the system. Either way, prototyping speeds up the development process significantly. A possible disadvantage of prototyping is that important decisions might be made too early, before business or IT issues are thoroughly understood. If a prototype is based on careful fact-finding and modeling techniques, however, it can be an extremely valuable tool.

3. Computer-Aided Systems Engineering
Computer-aided system engineering (CASE) is a technique that use powerful programs, called CASE tools, to help systems analysts develop and maintain information systems. CASE tools provided an overall framework for systems development and support a wide variety of design methodologies, including structured analysis and object-oriented analysis. Traditionally, systems developers differentiated between two CASE categories: upper CASE tools and lower CASE tools. Upper CASE tools support the modeling process and produce a logical design of the information system. Lower CASE tools speed the development process by generating source code based on the logical model. Today, many popular CASE tools combine upper and lower CASE features into a single product. CASE tools can boost IT productivity and improve the quality of the finished product. For example, developers use CASE tools to maintain design integrity, manage a complex project, and generate code modules that speed up implementation.

4. Joint Application Development and Rapid Application Development
In the past, the IT department typically developed information I systems and contacted users only when their input was desired or needed. Unfortunately that approach often left large communication gaps between system developers and users. Over time, many companies discovered that systems development teams composed of IT staff, user, and managers could complete their work more rapidly and produce better results. Two
methodologies became popular: joint application development (JAD) and rapid application development (RAD). Both approaches use teams composed of user, managers, and IT staff to complete projects. JAD involves team-based fact-finding techniques, while RAD is more like a condensed version fo the entire development process.

5. Other Systems Development Tools
In addition to CASE tools, a systems analyst uses various productivity tools or organize and structure the task of developing an information system.
In addition to word processing, spreadsheets, graphics tools, and presentation software, analysts use special purpose charting tools. A popular example is VISIO, which. A systems analyst can use Microsoft VISIO to draw flowcharts, data flow diagrams, network diagrams, and business process diagrams, among others.


OVERVIEW OF SYSTEMS DEVELOPMENT METHODOLOGIES

This section discusses the most popular methodologies for developing computer-based information systems. A popular, traditional method is called structured analysis, but a newer strategy called object-oriented analysis and design also is widely used. Each method offers many variations. Some organizations develop their own approaches or adopt methods offered by software vendors or consultants. Most IT experts agree that no single, best system development strategy exists. Instead, a systems analysis should understand the alternative methodologies and their strengths and weaknesses.

1. Structure Analysis
Structured analysis is a traditional systems development technique that is time-tested and easy to understand. Structured analysis evolves in a 1960s environment, where most systems were based on mainframe processing of individual data files. Because it describes the processing that transforms data into useful information, structured analysis includes data organization and structure, relational database design, and user interface issues. Structured analysis uses a series of phase, called the systems development life cycle (SDLC) to plan, analyze, design, implement, and support a n information system. Structured analysis relies on a set of process models that graphically describe a system. Process modeling identifies the data flowing into a process, the business rules that transforms the data, and resulting output data flow. Structured analysis is developing into a technique called information engineering. Information engineering, like enterprise computing, envisions the overall business enterprise and how corporate data and processes interact throughout the organization.

2. Object-Oriented Analysis
Whereas structured analysis regards processes and data as separate components, object-oriented (O-O) analysis combines data and the processes that act on the data into thing called objects. Systems analysts use O-O methods to model real-world business processes and operations. The result is a set of software objects that represent actual people, things,
transactions, and events. Using an O-O programming language, a programmer then transforms the object it into reusable code and components.
An object is member of a class, which is collection of similar objects. Objects posses characteristics called properties, which it inherits from its class or possess on its own. In O-O programming, built-in processes called methods can exchange an object’s properties. For example, a sailboat object might have a property named sailing speed that can be changed by methods that raise and lower its sails. One object can send information to another object by using a message.
A message can request specific behavior or information from the recipient. For example, if there if there is no wind, a sailboat owner object might send a “start the motor” message to the sailboat object. The owner object has the capability to send this message, and the sailboat object knows what action to perform when it receives he message. O-O analysis uses object models to represent data, behavior, by what means objects affects other objects. By describing an objects (data) and methods (processes) needed to support a business operation, a system developer can design reusable components that allow faster system implementation and decreased development cost. Many analysts believe that, compared with structured analysis, O-O method are more flexible, efficient, and realistic in today’s dynamic business
environment. Also O-O analysis provides an easy transition to popular O-O programming languages, such as Java C++.

3. Other development strategies
In addition to structured analysis and O-O methodologies, you might encounter other systems development techniques created by individual companies. For example, Microsoft has developed an approach called Microsoft Solutions Framework (MSF), Using MSF, you design a series of models, including a risk of management model, a team model, and a process model, among others. Each model has a specific purpose and outputs that contribute to the overall design of the system. Although the Microsoft process differs from the SDLC
phase-oriented approach, MSF, developers do the same kind of planning, ask the same kind of fact-finding question, deal with the same kinds of design and implementation issues, and resolve the same kinds of problems. MSF uses O-O analysis and design concepts, but also examines a broader business and organizational context that surrounds the development of an
information system. Companies often choose to follow their own methodology. By using
powerful CASE tools, an IT staff can apply a variety of techniques rather than being bound to a single, rigid methodology.