Embed Size (px)
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
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
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.
Ditulis dalam Manajemen TI, Teknologi Informasi | Bertanda software, standar dokumentasi,
standar dokumentasi pengembangan software, UML | 6 Komentar
Be the first to like this post.
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!
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
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-
Standar dokumentasi adalah buku panduan standar menyajikan report pengembangan
aplikasi, dalam hal ini untuk kemudahan perusahaan yang sering melakukan
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
punya contoh format dokumentasi yang baik?
boleh saya minta?
untuk dijadikan referensi.
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.
However, variants of the idea existed previously,
and have been devised subsequently.
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
7 Further reading
8 External links
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".
 The building blocks: entities, relationships, and
Two related entities
An entity with an attribute
A relationship with an attribute
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.
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
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.
 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
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
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:
(min, max)-notation of Jean-Raymond Abrial in 1974
UML class diagrams
 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.
 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
, 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
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
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.
1 ER Diagram (Entity-relationship model)
2 The Design Process
3 Determining data to be stored
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
8 Further reading
9 External links
 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.
 The Design Process
The design process consists of the following steps
1. Determine the purpose of your database - This helps prepare you for the remaining
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
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.
 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
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.
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
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.
 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)
 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.)
 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.
 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