Banyak Perusahaan Tidak Mempunyai Standar

Dokumentasi Pengembangan Software

April 2, 2008 oleh Arry Akhmad Arman

Bagaimanapun bentuknya, saya kira perusahaan-perusahaan besar pada umumnya

mempunyai standar proses pengembangan software yang secara umum biasanya disebut

SDLC (Software Development Life Cycle). Di beberapa perusahaan yang manajemen TI nya

sudah mapan, SDLC tersebut biasanya diterapkan secara konsisten baik untuk pengembangan

software oleh pihak internal, maupun pengembangan software yang melibatkan pihak

eksternal (outsourcing). SDLC yang diterapkan secara ketat secara tidak langsung akan

meningkatkan kualitas software yang dihasilkan. Bagian dari SDLC juga mensyaratkan

adanya dokumentasi software yang baik.

Apakah SDLC saja serta keberadaan dokumentasi software sudah cukup? Jawabannya

biasanya baru diketahui setelah ada masalah-masalah berkaitan dengan software aplikasi

yang sudah pernah dibuat. Beberapa permasalahan tipikal diantaranya adalah sebagai berikut:

1. Dokumentasi software ternyata tidak lengkap, ada bagian penting dari software yang

tidak dijelaskan dengan cukup, sehingga sulit untuk memahaminya.

2. Format dan struktur dokumen berbeda-beda

3. Cara pemodelan berbeda-beda. Mungkin ada yang masih menggunakan flowchart +

ER Diagram saja, ada yang menambahkan Data Flow Diagram (DFD), ada yang

mencampur adukan UML dengan DFD, atau ada yang secara penuh sudah

menerapkan UML.

Permasalahan-permasalahan tersebut di atas akan menghambat tujuan-tujuan sebagai berikut:

1. Melakukan modifikasi software menjadi sulit dilakukan. Kadang perusahaan

ingin melakukan modifikasi kecil dari software yang sudah dibuat dan sudah diluar

masa garansi. Tapi sulit dilakukan karena hambatan dokumentasi.

2. Melakukan pengembangan lebih lanjut menggunakan vendor lain. Dokumentasi

yang buruk, yang hanya dimengerti oleh pembuatnya saja, menyulitkan dipahami oleh

pihak lain yang akan meneruskan pekerjaan tersebut.

3. Melakukan integrasi dengan aplikasi lain. Ketika sistem berkembang dan ada

tuntutan integrasi, dokumentasi yang buruk mungkin akan menyulitkan untuk

memahami struktur data, cara berkomunikasi data, apalagi kalau ada keperluan

modifikasi algoritma untuk mencapai tujuan integrasi.

Bagaimana solusinya? Sederhana!

Buatlah standar (template) dokumentasi pengembangan software aplikasi di

perusahaan anda. Standar dokumentasi berbeda dengan standar proses pengembangan

(SDLC).

Semua pengembangan software, baik yang dilakukan oleh pihak internal maupun cara

outsource harus membuat dokumentasi sesuai standar tersebut. Hal yang harus diingat adalah:

Jangan membuat standar dokumentasi yang bentuknya tidak biasa. Saya sarankan untuk

mengadopsi dari suatu standar, lalu lakukan penyesuaian minor. Untuk pemodelannya, saya

menganjurkan untuk menggunakan UML secara penuh.

Nah, kalau ini sudah tercapai, anda buka dokumen software manapun selalu sama bentuknya

dan kelengkapannya cenderung lebih terjamin karena mengikuti template yang sudah ada.

Semoga bermanfaat!

Ditulis dalam Manajemen TI, Teknologi Informasi | Bertanda software, standar dokumentasi,

standar dokumentasi pengembangan software, UML | 6 Komentar

Suka

Be the first to like this post.

6 Tanggapan

1. pada April 2, 2008 pada 9:48 am | Balas kaitokid724

Tulisan artikel di blog Anda bagus-bagus. Agar lebih bermanfaat lagi, Anda bisa lebih

mempromosikan dan mempopulerkan artikel Anda di infoGue.com ke semua

pembaca di seluruh Indonesia. Salam Blogger!

http://www.infogue.com/

http://www.infogue.com/bisnis_keuangan/banyak_perusahaan_tidak_mempunyai_sta

ndar_dokumentasi_pengembangan_software/

2. pada April 2, 2008 pada 12:32 pm | Balas Identifikasi Ancaman dalam Disaster

Recovery Jangan Terfokus Hanya Pada Bencana Alam | Sharing Vision

[...] Artikel diambil dari sini, dari Blog Arry Akhmad [...]

3. pada April 2, 2008 pada 1:01 pm | Balas ayi purbasari

SW = program + data + dokumentasi

Tepat sekali bu!

4. pada Desember 16, 2008 pada 8:45 pm | Balas agus sukoco

Buatlah standar (template) dokumentasi pengembangan software aplikasi di

perusahaan anda. Standar dokumentasi berbeda dengan standar proses pengembangan

(SDLC).??

standardnya apa ya?

5. pada Desember 17, 2008 pada 7:19 am | Balas Arry Akhmad Arman

SDLC hanya menjelaskan siklus. Pengembangan yang menggunakan siklus yang

sama bisa mempunyai cara mendokumentasikan yang berbeda-beda. MUngkin

semuanya benar, tidak ada yang salah, tetapi itu akan menyulitkan bagi perusahaan

yang sering melakukan outsource pengembangan aplikasi, karena style-nya berbeda-

beda.

Standar dokumentasi adalah buku panduan standar menyajikan report pengembangan

aplikasi, dalam hal ini untuk kemudahan perusahaan yang sering melakukan

outsource.

SDLC bisa dipilih yang manapun. Walaupun paling kuno, Waterfall masih sering

digunakan, karena lebih memudahkan dari sisi manajemen proyek.

Standar dokumentasi, sebaiknya simbol-simbolnya menggunakan UML dan diatur

penulisannya dengan ketat.

6. pada Juli 22, 2010 pada 5:50 pm | Balas Indri

Maaf pak,

punya contoh format dokumentasi yang baik?

boleh saya minta?

untuk dijadikan referensi.

thanks…

From Wikipedia, the free encyclopedia

Jump to: navigation, search

A sample Entity-relationship diagram using Chen's notation

In software engineering, an entity-relationship model (ERM) is an abstract and conceptual

representation of data. Entity-relationship modeling is a database modeling method, used to

produce a type of conceptual schema or semantic data model of a system, often a relational

database, and its requirements in a top-down fashion. Diagrams created by this process are

called entity-relationship diagrams, ER diagrams, or ERDs.

The definitive reference for entity-relationship modeling is Peter Chen's 1976 paper.[1]

However, variants of the idea existed previously,[2]

and have been devised subsequently.

Contents

[hide]

1 Overview

2 The building blocks: entities, relationships, and attributes

3 Diagramming conventions

o 3.1 Crow's Foot Notation

4 ER diagramming tools

5 See also

6 References

7 Further reading

8 External links

[edit] Overview

The first stage of information system design uses these models during the requirements

analysis to describe information needs or the type of information that is to be stored in a

database. The data modeling technique can be used to describe any ontology (i.e. an overview

and classifications of used terms and their relationships) for a certain area of interest. In the

case of the design of an information system that is based on a database, the conceptual data

model is, at a later stage (usually called logical design), mapped to a logical data model, such

as the relational model; this in turn is mapped to a physical model during physical design.

Note that sometimes, both of these phases are referred to as "physical design".

[edit] The building blocks: entities, relationships, and

attributes

Two related entities

An entity with an attribute

A relationship with an attribute

Primary key

An entity may be defined as a thing which is recognized as being capable of an independent

existence and which can be uniquely identified. An entity is an abstraction from the

complexities of some domain. When we speak of an entity we normally speak of some aspect

of the real world which can be distinguished from other aspects of the real world.[3]

An entity may be a physical object such as a house or a car, an event such as a house sale or a

car service, or a concept such as a customer transaction or order. Although the term entity is

the one most commonly used, following Chen we should really distinguish between an entity

and an entity-type. An entity-type is a category. An entity, strictly speaking, is an instance of

a given entity-type. There are usually many instances of an entity-type. Because the term

entity-type is somewhat cumbersome, most people tend to use the term entity as a synonym

for this term.

Entities can be thought of as nouns. Examples: a computer, an employee, a song, a

mathematical theorem.

A relationship captures how two or more entities are related to one another. Relationships can

be thought of as verbs, linking two or more nouns. Examples: an owns relationship between a

company and a computer, a supervises relationship between an employee and a department, a

performs relationship between an artist and a song, a proved relationship between a

mathematician and a theorem.

The model's linguistic aspect described above is utilized in the declarative database query

language ERROL, which mimics natural language constructs.

Entities and relationships can both have attributes. Examples: an employee entity might have

a Social Security Number (SSN) attribute; the proved relationship may have a date attribute.

Every entity (unless it is a weak entity) must have a minimal set of uniquely identifying

attributes, which is called the entity's primary key.

Entity-relationship diagrams don't show single entities or single instances of relations. Rather,

they show entity sets and relationship sets. Example: a particular song is an entity. The

collection of all songs in a database is an entity set. The eaten relationship between a child

and her lunch is a single relationship. The set of all such child-lunch relationships in a

database is a relationship set. In other words, a relationship set corresponds to a relation in

mathematics, while a relationship corresponds to a member of the relation.

Certain cardinality constraints on relationship sets may be indicated as well.

[edit] Diagramming conventions

Entity sets are drawn as rectangles, relationship sets as diamonds. If an entity set participates

in a relationship set, they are connected with a line.

Attributes are drawn as ovals and are connected with a line to exactly one entity or

relationship set.

Cardinality constraints are expressed as follows:

a double line indicates a participation constraint, totality or surjectivity: all entities in

the entity set must participate in at least one relationship in the relationship set;

an arrow from entity set to relationship set indicates a key constraint, i.e. injectivity:

each entity of the entity set can participate in at most one relationship in the

relationship set;

a thick line indicates both, i.e. bijectivity: each entity in the entity set is involved in

exactly one relationship.

an underlined name of an attribute indicates that it is a key: two different entities or

relationships with this attribute always have different values for this attribute.

Attributes are often omitted as they can clutter up a diagram; other diagram techniques often

list entity attributes within the rectangles drawn for entity sets.

Two related entities shown using Crow's Foot notation

Chen's notation for entity-relationship modeling uses rectangles to represent entities, and

diamonds to represent relationships appropriate for first-class objects: they can have

attributes and relationships of their own.

Related diagramming convention techniques:

Bachman notation

EXPRESS

IDEF1X[4]

Martin notation

(min, max)-notation of Jean-Raymond Abrial in 1974

UML class diagrams

[edit] Crow's Foot Notation

Crow's Foot notation is used in Barker's Notation, SSADM and Information Engineering.

Crow's Foot diagrams represent entities as boxes, and relationships as lines between the

boxes. The ends of these lines are shaped to represent the cardinality of the relationship.

Usage of Chen notation is more prevalent in the United States, while Crow's Foot notation is

used primarily in the UK. Crow's Foot notation was used in the 1980s by the consultancy

practice CACI. Many of the consultants at CACI (including Barker) subsequently moved to

Oracle UK, where they developed the early versions of Oracle's CASE tools, introducing the

notation to a wider audience. Crow's Foot notation is used by these tools: ARIS, System

Architect, Visio, PowerDesigner, Toad Data Modeler, DeZign for Databases, Devgems Data

Modeler, OmniGraffle, and MySQL Workbench. CA's ICASE tool, CA Gen aka

Information_Engineering_Facility also uses this notation.

[edit] ER diagramming tools

There are many ER diagramming tools. Some free software ER diagramming tools that can

interpret and generate ER models, SQL and do database analysis are MySQL Workbench

(formerly DBDesigner), and Open ModelSphere (open-source). A freeware ER tool that can

generate database and application layer code (webservices) is the RISE Editor. The Open

Source Erviz takes a simple textual description of the ERD and then uses Graphviz to

automatically produce a nice, if slightly spaced out, layout.

Some of the proprietary ER diagramming tools are ARIS, Avolution, Aqua Data Studio,

dbForge Studio for MySQL, DeZign for Databases, ER/Studio, Devgems Data Modeler,

ERwin, MEGA International, ModelRight, OmniGraffle, Oracle Designer, PowerDesigner,

Rational Rose, Sparx Enterprise Architect, SQLyog, System Architect, Toad Data Modeler,

SQL Maestro, Microsoft Visio, Visible Analyst, and Visual Paradigm.

Some free software diagram tools just draw the shapes without having any knowledge of

what they mean, nor do they generate SQL. These include Gliffy[5]

, Kivio and Dia. DIA

diagrams, however, can be translated with tedia2sql.

Database design is the process of producing a detailed data model of a database. This logical

data model contains all the needed logical and physical design choices and physical storage

parameters needed to generate a design in a Data Definition Language, which can then be

used to create a database. A fully attributed data model contains detailed attributes for each

entity.

The term database design can be used to describe many different parts of the design of an

overall database system. Principally, and most correctly, it can be thought of as the logical

design of the base data structures used to store the data. In the relational model these are the

tables and views. In an object database the entities and relationships map directly to object

classes and named relationships. However, the term database design could also be used to

apply to the overall process of designing, not just the base data structures, but also the forms

and queries used as part of the overall database application within the database management

system (DBMS).[1]

The process of doing database design generally consists of a number of steps which will be

carried out by the database designer. Usually, the designer must:

Determine the relationships between the different data elements.

Superimpose a logical structure upon the data on the basis of these relationships.[2]

Contents

[hide]

1 ER Diagram (Entity-relationship model)

2 The Design Process

3 Determining data to be stored

4 Normalization

5 Types of Database design

o 5.1 Conceptual schema

o 5.2 Logically structuring data

o 5.3 Physical database design

6 See also

7 References

8 Further reading

9 External links

[edit] ER Diagram (Entity-relationship model)

A sample Entity-relationship diagram

Database designs also include ER(Entity-relationship model) diagrams. An ER diagram is a

diagram that helps to design databases in an efficient way.

Attributes in ER diagrams are usually modeled as an oval with the name of the attribute,

linked to the entity or relationship that contains the attribute.

Within the relational model the final step can generally be broken down into two further

steps, that of determining the grouping of information within the system, generally

determining what are the basic objects about which information is being stored, and then

determining the relationships between these groups of information, or objects. This step is not

necessary with an Object database.[2]

[edit] The Design Process

The design process consists of the following steps[3]

:

1. Determine the purpose of your database - This helps prepare you for the remaining

steps.

2. Find and organize the information required - Gather all of the types of information

you might want to record in the database, such as product name and order number.

3. Divide the information into tables - Divide your information items into major

entities or subjects, such as Products or Orders. Each subject then becomes a table.

4. Turn information items into columns - Decide what information you want to store

in each table. Each item becomes a field, and is displayed as a column in the table.

For example, an Employees table might include fields such as Last Name and Hire

Date.

5. Specify primary keys - Choose each table’s primary key. The primary key is a

column that is used to uniquely identify each row. An example might be Product ID

or Order ID.

6. Set up the table relationships - Look at each table and decide how the data in one

table is related to the data in other tables. Add fields to tables or create new tables to

clarify the relationships, as necessary.

7. Refine your design - Analyze your design for errors. Create the tables and add a few

records of sample data. See if you can get the results you want from your tables. Make

adjustments to the design, as needed.

8. Apply the normalization rules - Apply the data normalization rules to see if your

tables are structured correctly. Make adjustments to the tables.

[edit] Determining data to be stored

In a majority of cases, a person who is doing the design of a database is a person with

expertise in the area of database design, rather than expertise in the domain from which the

data to be stored is drawn e.g. financial information, biological information etc. Therefore the

data to be stored in the database must be determined in cooperation with a person who does

have expertise in that domain, and who is aware of what data must be stored within the

system.

This process is one which is generally considered part of requirements analysis, and requires

skill on the part of the database designer to elicit the needed information from those with the

domain knowledge. This is because those with the necessary domain knowledge frequently

cannot express clearly what their system requirements for the database are as they are

unaccustomed to thinking in terms of the discrete data elements which must be stored. Data

to be stored can be determined by Requirement Specification.[4]

[edit] Normalization

Main article: Database normalization

In the field of relational database design, normalization is a systematic way of ensuring that

a database structure is suitable for general-purpose querying and free of certain undesirable

characteristics—insertion, update, and deletion anomalies—that could lead to a loss of data

integrity.

A standard piece of database design guidance is that the designer should create a fully

normalized design; selective denormalization can subsequently be performed, but only for

performance reasons. However, some modeling disciplines, such as the dimensional

modeling approach to data warehouse design, explicitly recommend non-normalized designs,

i.e. designs that in large part do not adhere to 3NF.

[edit] Types of Database design

This section does not cite any references or sources. Please help improve this article by adding citations to reliable sources. Unsourced material may be

challenged and removed. (August 2010)

[edit] Conceptual schema

Main article: Conceptual schema

Once a database designer is aware of the data which is to be stored within the database, they

must then determine where dependancy is within the data. Sometimes when data is changed

you can be changing other data that is not visible. For example, in a list of names and

addresses, assuming a situation where multiple people can have the same address, but one

person cannot have more than one address, the name is dependent upon the address, because

if the address is different, then the associated name is different too. However, the other way

around is different. One attribute can change and not another.

(NOTE: A common misconception is that the relational model is so called because of the

stating of relationships between data elements therein. This is not true. The relational model

is so named because it is based upon the mathematical structures known as relations.)

[edit] Logically structuring data

Once the relationships and dependencies amongst the various pieces of information have

been determined, it is possible to arrange the data into a logical structure which can then be

mapped into the storage objects supported by the database management system. In the case of

relational databases the storage objects are tables which store data in rows and columns.

Each table may represent an implementation of either a logical object or a relationship joining

one or more instances of one or more logical objects. Relationships between tables may then

be stored as links connecting child tables with parents. Since complex logical relationships

are themselves tables they will probably have links to more than one parent.

In an Object database the storage objects correspond directly to the objects used by the

Object-oriented programming language used to write the applications that will manage and

access the data. The relationships may be defined as attributes of the object classes involved

or as methods that operate on the object classes.

[edit] Physical database design

The physical design of the database specifies the physical configuration of the database on

the storage media. This includes detailed specification of data elements, data types, indexing

options and other parameters residing in the DBMS data dictionary. It is the detailed design

of a system that includes modules & the database's hardware & software specifications of the

system.