Membuat Use Case dan Use Case Description 2

Berikut ini adalah sebuah teknik pembuatan Use Case Diagram pada studi kasus aplikasi berbasis Web 2.0. Langkah-langkah penentuan requirements, mengikuti pendekatan agile, yakni dimulai dengan pendefinisian masalah, kemudian dilanjutkan dengan pemodelan permasalahan. Persyaratan perangkat lunak, dikelompokkan dengan teknik QFD, dan menghasilkan persyaratan fungsional dan non fungsional.

1.1 Background

The using of internet by the government instituion and society rapidly grow. Internet user grows in number and services. North Sulawesi Local Government, especially the office of Investment Expert Staff seeing this phenomena as opportunity to promote exotic tourism. Using Web 2.0 technology to create competitive advantage as strategic and crusial considerations to foster investment climate for North Sulawesi tourism. Utilization of Web based 2.0 technology is expected to improve service, market share and shaping public opinion by providing targeted and comprehensive information on North Sulawesi exotic tourism, which is easily obtained by anyone, anywhere, anytime using any device.

1.2 Problems

Exotic tourism places owned by North Sulawesi Province is threatened by the onslaught of tourism promotions of some new netrants such as Wakatobi and Raja Amplat. While the number of foriegn tourist realtively declined over the 5 years before, the tourism potential of Bunaken National Park is not fully optimized by stakeholders. Lack of comprehensive information about Bunaken National Park is one of the resons for the decline of foreign tourist visiting. Structuring a comprehensive information related to the potential of tourism placesm tourism activities is one of a strategic solution that must be done to fix the pre-eminent tourism promotion. In addtion, the information must be displayed in such as interative user interface, constantly available for 24/7 and able to be found easily. Web Portal Amazing North Sulawesi is expected to be effective solution.

1.3 Functional Requirements

List of functional requirements are:
1). Viewing Info
1.1 The system can display information about the ads, profile, headline news, main headline news, North Sulawesi Profile and general articles.
1.2  The system can display links.
1.3  The system can displat visitor counter for each pages.
1.4 The system can display currency value and weather report.
2). Managing Info
2.1 Input ads, profile, news, headline, main headline and articles.
2.2 Edit ads, profile, news, headline, main headline and articles.
2.3 Delete ads, profile, news, headline, main headline and articles
2.4 Save ads, profile, news, headline, main headline and articles.
3). Collaborating
3.1 The system must provide facilities for  posting and reply comments for news, headline, main headline and articles.
3.2 The system must provide sharing and collaborating tools for social media, i.e: facebook, twitter dan G+.
3.3  The system musti provide polling feature.

1.4. Non-Functional Requirements
For non-functional requirements are distinguished in terms of operational, performance and security. Some non-functional terms to be met by the system are as follows:
Operational Requirements (the physical and technical systems that apply):
1) The system must be displayed in Indonesian and English
2) The system can be operated on a smartphone, desktop and notebook on the optimal display resolution.
3) The system must be able to work on all web browsers.
4) The System must running through the operating system Windows and Linux.
Performance Requirements (speed, capacity and reliability):
1) The system must be used or operated within 24 hours a day, 7 days a week and 356 days a year.
2) Each user interaction with the system should not be longer than 3 seconds.
Security Requirements
1) The system must provide privilege access for groups of admins and users.
2) The system must provide verification procedure for posting comments.

Gambar Use Case dan Use Case Description adalah sebagai berikut:

Membuat Use Case dan Use Case Description

Membangun use case model, merupakan salah satu kompetensi yang HARUS dikuasai oleh seorang software engineers. Apalagi saat menggunakan pendekatan model driven engineering dan membangun aplikasi berorientasi object, maka kemampuan membuat use case model survey, menjadi sangat krusial. Tentu saja, dengan melatih diri berulang-ulang, maka kompetensi membuat use case model survey akan makin baik.

Berikut saya berikan sebuah contoh, membuat use case model pada aplikasi tes online. Langkah penyelesaiannya adalah 1.1 Membuat deskripsi masalah yang akan diselesaikan; 1.2 Membuat model penyelesaian masalah. Kemudian melakukan 1.3 Requirements Capturing. Berikut adalah penjelesan detailnya:

1.1 Problem description

This case study comprises an electronic examining system. A teacher makes use of the system to give an examination to her/his students. We assume that creating an examination is a separate task performed out of the scope of the examining system. This system should be made available on the web, so that both the teacher and the students have remote access to it. 

A teacher creates a test and stores this test into a test repository. Afterwards the teacher can assign this test to a group of students. There can be different types of tests but all of them must have a deadline defined by the teacher. So, for example the teacher may propose an examination in which the students are requested to write an essay about a certain subject or to solve some questions. The former activity may take several days to be completed while the latter may take only a limited number of minutes. The teacher also evaluates a student’s test answer by attaching comments and grading it.

When a student access the system, this student can consult his/her personal profile and do a test. A student personal profile contains his/her personal information, the list of tests to be done and the answers, grades and comments of completed tests. A student does a test by submitting the answers for this test. Once an answer is submitted it can not be resubmitted. All the student personal profiles are stored in a profile repository, however the access of a student is limited to his/her personal profile.

1.2 Problem modelling

This section reports the results of case study modelling activities. Each of the following subsections presents some of the results of these activities, viz., requirements capturing and analysis. The complete UML documentation of this case study can be found in Fig below. The development of this case study was performed making use of Rational Rose as a modelling support tool.

1.3 Requirements capturing

The requirements of the electronic examining system were captured by means of a use case diagram according to the following steps:

1. Identification of the actors;

2. Identification of the use cases;

3. Description of each use case.

1) Process Identification of the Actors

The identification of the actors of the system was straightforward. We simply identified the roles of the potential users of the system. The identified actors are the following:

• Student, who is a person who takes exams and consults some personal and test related information that are stored in his/her profile. The student has limited access rights to the system;

• Teacher, who is a person that assigns tests to groups of students and grade the assigned tests. The teacher has full rights to the system.

2) Process Identification of the use cases

The identification of the use cases was more complex. As a rule of thumb to identify a use case we considered the following criteria: a use case should represent a sequence of related actions that provide some functionality to the actor when successfully executed. Whenever a variation on a normal behaviour or a repetition of a separate use case were identified, the extends and uses relationships between use cases were used. 

The identified use cases are the following:

• Access Student Profile, which is used to access the student profiles. All student profiles are kept in a profile repository ordered according to the student groups that the student belongs. The teacher reads and writes the student profile, while the student reads the student profile. The student can write to his/her profile only the test results. 

• Access Test Repository, which is used to access the test repository. The teacher can read and write to the test repository, while the student can read from the test repository only the tests that are assigned to his/her profile.

• Assign Test, which is used to select a test from the test repository and assign the selected test to a group of students.

• Consult Profile, which is used to consult a student personal profile. The student profile contains the student personal information, the tests to be done, the test answers and the grades received so far. The student profiles are stored in a profile repository. A student has access rights only to his/her personal profile.

• Do Test, which is used to do a test. The student selects one of the tests from his/her profile. The student retrieves this test from the test repository. Then, the student does the test and submits the test answers, which are stored in his/her profile.

• Evaluate Test, which is used to evaluate a performed test. The evaluation of a test consists of making comments concerning the answers provided and grading the test. The teacher first selects a test to be evaluated and then retrieves from the student profiles some or all the answers provided for that test.

• Register Test, which is used to register and store one test in the test repository.

Each use case was described briefly, by means of few sentences that summarises the actions (see previous use case descriptions), and in a step-by-step manner, by means of a detailed description of what the system needs to do when interacting with its actors. 

Detailed Use cases Description

1. Access Student Profile

This use case is used to access the student profiles All student profiles are kept in a profile repository ordered according to the student groups that the student belongs. The teacher reads and writes the student profile, while the student reads the student profile. The student can write to his/her profile only the test results. 

----------------------------------------------

Detailed use case description (I):

1 - Teacher assigns a test to group of students.

Detailed use case description (II):

1 - Teacher retrieves a student test answer

2 - Teacher adds a comment to the test answer.

3 - Teacher grades the test answer.

PS: 2 is optional. 1/2/3 can be executed in any order.

Detailed use case description (III):

1 - Student browses his/her personal information.

2 - Student browses his/her test list.

3 - Student browses his/her grade list.

4 - Student browses his/her test comments.

PS: 1/2/3/4 can be executed in any order.

Detailed use case description (IV):

1 - Student selects a test to do.

2 - Student does a test, storing the test result into his/her personal profile.

2. Access Test Repository

This use case is used to access the test repository. The teacher can read and write to the test repository, while the student can read from the test repository only the tests that are assigned to his/her profile.

----------------------------------------------

Detailed use case description (I):

1 - Teacher stores a test into the test repository.

Detailed use case description (II):

1 - Teacher browses the tests available in the test repository.

Detailed use case description (III):

1 - Teacher retrieves a test from the test repository. 

Detailed use case description (IV):

1 - Student reads a test from the test repository with restrictions.

3. Assign Test 

This use case is used to select a test from the test repository and assign the selected test to a group of students.

---------------------------------------------

Detailed use case description:

1 - Teacher browses test list/repository

2 - Teacher select a test and assign it to a group of students. The selected test is added to the test list of the group of students.

4.Consult Profile

This use case is used to consult a student personal profile. The student profile contains the student personal information, the tests to be done, the test answers and the grades received so far. The student profiles are stored in a profile repository. A student has access rights only to his/her personal profile.

-------------------------------------------

Detailed description:

1 - Student browses his/her personal information.

2 - Student browses his/her assigned test.

3 - Student browses his/her grades.

4 - Student browses his/her test comments.

PS: 1/2/3/4 can be executed in any order.

5. Do Test

This use case is used to do a test. The student selects one of the tests from his/her profile. The student retrieves this test from the test repository. Then, the student does the test and submits the test answers, which are stored in his/her profile.

----------------------------------------------

Detailed use case description:

1 - Student selects a test from the test list.

2 - Selected test is loaded from the test repository.

3 - Student does the test. Test answers are stored stored in the student profile.

6. Evaluate Test

This use case is used to evaluate a performed test. The evaluation of a test consists of making comments concerning the answers provided and grading the test. The teacher first selects a test to be evaluated and then retrieves from the student profiles some or all the answers provided for that test.

----------------------------------------------

Detailed description:

1 - Teacher retrieves the test from the test repository.

2 - Teacher retrieves student test answers from the profile repository.

3 - Teacher adds comment to the student test 

4 - Teacher grades the student test

PS: 3 is optional

7. Register Test

This use case is used to register and store a test into the test repository.

--------------------------------------------

Detailed use case description: 

1 - Teacher registers a test to the test repository. The test is stored into the test repositor.

Gambar Use Case dari Studi Kasus diatas adalah ...

QFD dan Elisitasi Software Requirements

Terdapat beberapa teknik untuk mendefinisikan persyaratan perangkat lunak. Salah satunya adalah yang disebut Quality function deployment (QFD). Pressman menjelaskan bahwa QFD merupakan salah satu teknik manajemen kualitas yang dapat "menterjemahkan" kebutuhan pelanggan ke dalam bentuk persyaratan software yang teknis; dengan berpedoman pada kebutuhan pelanggan. Teknik QFD dimulai dengan mengklasifikasikan requirements ke dalam tiga tipe yakni normal, expected dan exciting. Kebutuhan "normal" adalah persyaratan yang mandatory dikembangkan oleh tim pengembang. Sementara untuk kategori expected dan exciting adalah persyaratan yang dapat "ditunda". Klasifikasi pesyaratan kebutuhan ini didasarkan atas value (atau manfaat) yang bisa diperoleh dari implementasi fitur tersebut pada sistem aplikasi perangkat lunak yang akan dikembangkan. Tentu saja dibutuhkan sebuah proses yang disebut "value analysis" untuk mengidentifikasi secara lengkap setiap persyaratan perangkat lunak tersebut.

Melakukan elisitasi persyaratan perangkat lunak, bukanlah pekerjaan yang mudah, meski demikian dengan sering melakukan latihan, maka tim pengembang akan makin baik. Penyebabnya adalah user yang sering tidak memahami perangkat lunak yang akan dibangun dan komunikasi tim pengembang yang tidak efektif. Kedua faktor ini sering menyebabkan "gagalnya" proses elisitasi mendapatkan persyaratan perangkat lunak dengan lengkap.

Menurut Pressman, terdapat beberapa produk yang dapat dihasilkan dari proses elisitasi persyaratan perangkat lunak ini, diantaranya adalah:

1) Statement of need and feasibility

2) Bounded statement of scope for system or product

3) List of stakeholders involved in requirements elicitation

4) Description of system’s technical environment

5) List of requirements organized by function and applicable domain constraints

6) Set of usage scenarios (use-cases) that provide use insight into operation of deployed system

7) Prototypes developed to better understand requirements 

Setelah melakukan proses elisitasi persyaratan perangkat lunak, maka tim pengembang akan membuat dokumen vision. Sebuah contoh dari dokumen vision tersebut dapat dilihat disini:

https://docs.google.com/file/d/0BxSxy7HfW5oJc0xhQVlqdUN0bTA/edit

Untuk penjelasan lebih mendalam mengenai teknik QFD dapat mengacu pada URL dibawah ini:

1. http://en.wikipedia.org/wiki/Quality_function_deployment

2. http://www.qfdi.org/

3. http://www.qfdi.org/what_is_qfd/what_is_qfd.htm

4. http://www.qfdonline.com/

dan

5. http://www.ciri.org.nz/downloads/Quality%20Function%20Deployment.pdf

Memahami Requirements Perangkat Lunak

Memahami requirements perangkat lunak, merupakan langkah awal dalam pengembangan perangkat lunak. Apa sebenarnya yang dimaksud dengan requirements tersebut? Ada yang mengartikan requirements sebagai pendefinisian perangkat lunak. Beberapa pakar software engineering, mengartikan requirements perangkat lunak sebagai kebutuhan atau persyaratan perangkat lunak; yakni setiap fungsi yang dapat dilakukan perangkat lunak.

Menurut hemat saya, proses pendefinisian perangkat lunak, haruslah merupakan proses penyelesaian masalah. Jika kita berparadigma bahwa perangkat lunak dibangun dengan tujuan khusus tertentu, untuk melaksanakan fungsi khusus tertentu, maka sebagai sebuah produk, tentu saja, perangkat lunak ditujukan untuk menyelesaikan masalah tertentu. Pendekatan problem-solving ini, merupakan pendekatan rekayasa.

Lihat sebuah Gambar dibawah ini:

Gambar diatas merupakan langkah-langkah untuk menyelesaikan masalah tertentu. Proses requirements software pun mengikuti pola yang demikian. Pressman menyebutkan bahwa requirements engineering helps software engineers better understand the problems they are trying to solve. Ini berarti Pressman mengikuti paradigma software for solving problems. Jadi, proses pendefisian kebutuhan perangkat lunak adalah sebuah proses dimana pengembang dan stakeholders berusaha memahami permasalahan dan mencarikan solusi permasalahan tersebut, dengan mengembangkan perangkat lunak. Jiwa "problem solving" inilah yang harus dikembangkan tim pengembang perangkat lunak.

Tentu saja, melakukan pendefisinian kebutuhan perangkat lunak HARUS melibatkan stakeholders secara intim. Karena pada dasarnya, permasalahan stakeholder-lah yang ingin diselesaikan, oleh dan dengan perangkat lunak yang akan dikembangkan. Seperti yang diungkapkan Pressman bahwa ... it is very important to understand the customer’s wants and needs before you begin designing or building a computer-based solution ...
Selanjutnya Pressman menulis bahwa ... the intent of requirements engineering is to produce a written understanding of the customer’s problem ... Ini harus dipahami sebagai tujuan yang harus dicapai oleh stakeholders dan tim pengembang, yakni permasalahan yang ingin diselesaikan haruslah dalam bentuk tertulis (written problems). Tinjauan permasalahan yang tertulis merupakan hal penting lainnya dalam proses pendefinisian perangkat lunak, karena sifat manusia (baik stakeholders dan pengembang) yang cenderung berubah-ubah, maka mendapatkan written problems merupakan hal yang mandatory. Biasanya dokumentasi kebutuhan perangkat lunak itu ditulis sebagai SRS (software requirements specification). SRS akan berisi scenario users, daftar fungsi dan fitures yang akan dikembangkan, model diagram analisis kebutuhan hingga spesifikasi sistem yang akan dikembangkan.

Tahap Requirements Engineering yang dikemukakan Pressman:
1) Inception (software engineers use context-free questions to establish a basic understanding of the problem, the people who want a solution, the nature of the solution, and the effectiveness of the collaboration between customers and developers)
2) Elicitation (find out from customers what the product objectives are, what is to be done, how the product fits into business needs, and how the product is used on a day to day basis)
3) Elaboration (focuses on developing a refined technical model of software function, behavior, and information)
4) Negotiation (requirements are categorized and organized into subsets, relations among requirements identified, requirements reviewed for correctness, requirements prioritized based on customer needs)
5) Specification (written work products produced describing the function, performance, and development constraints for a computer-based system)
6) Requirements validation (formal technical reviews used to examine the specification work products to ensure requirement quality and that all work products conform to agreed upon standards for the process, project, and products)
7) Requirements management (activities that help project team to identify, control, and track requirements and changes as project proceeds, similar to  software configuration management (SCM) techniques

Dalam prakteknya, pendefinisian persyaratan merupakan ketrampilan, sehingga harus dilatih agar supaya menjadi mahir. Semakin sering, seorang pengembang melakukan komunikasi-terbuka dengan stakeholders maka, pendefinisian perangkat lunak akan semakin clear dan sharp.

Selanjutnya, silahkan melihat tulisan saya berikut ini, sebagai bagian lanjutan dari Memahami Requirements Perangkat Lunak:

http://stanlysk.blogspot.com/2012/07/requirements-engineering.html

 

Konsep Manajemen Proyek Perangkat Lunak

Perangkat Lunak, sekarang ini dikembangkan dengan pendekatan manajemen proyek. Apa artinya? Dalam hal ini, kita, sebagai pengembang perangkat lunak, memahami bahwa perangkat lunak itu adalah sebuah produk. Dan sebagaimana halnya sebuah produk, maka untuk menghasilkan produk yang berkualitas, perangkat lunak perlu dibuat dengan mengikuti alur proses tertentu yang terukur. Pengelolaan perangkat lunak merupakan hal penting dalam menjamin kualitas produk perangkat lunak itu sendiri.

Pressman mengemukakan beberapa pokok pikiran terkait konsep manajemen proyek perangkat lunak, diantaranya adalah:

1) Project management involves the planning, monitoring, and control of people, process, and events that occur during software development.

2) Everyone manages, but the scope of each person's management activities varies according his or her role in the project.

3) Software needs to be managed because it is a complex undertaking with a long duration time.

4) Managers must focus on the fours P's to be successful (people, product, process, and project).

5) A project plan is a document that defines the four P's in such a way as to ensure a cost effective, high quality software product.

6) The only way to be sure that a project plan worked correctly is by observing that a high quality product was delivered on time and under budget.

Pokok pikiran yang dikemukakan Pressman dapat menjadi dasar kerangka acuan berpikir dari pengembang perangkat lunak. Lihat pokok pikiran 3) misalnya, disitu disebutkan bahwa perangkat lunak, perlu dikelola karena merupakan produk yang kompleks, yang harus dikerjakan dalam kurun waktu tertentu yang relatif cukup lama. Hal ini sangat tepat, dalam konteks perangkat lunak dewasa ini. Sebuah aplikasi stand-alone saja sudah terdiri dari puluhan halaman kode (diukur dengan satun LOC atau Lines of Code); belum lagi ditambah dengan banyaknya "konektivitas" (misalnya koneksi antar-muka, koneksi basis data, jaringan dan sebagainya). Sesungguhnya isu kompleksitas perangkat lunak, merupakan isu yang tidak terbantahkan di era Web 2.0 sekarang ini. Rancang bangun perangkat lunak yang sederhana merupakan tantangan tersendiri bagi tim pengembang.

Mari kita lihat, pokok pikiran Pressman yang ke 4). Disini Pressman menekankan mengenai spektrum manajemen perangkat lunak, yakni:

1) People (recruiting, selection, performance management, training, compensation, career development, organization, work design, team/culture development) 

2) Product (product objectives, scope, alternative solutions, constraint tradeoffs)

3) Process (framework activities populated with tasks, milestones, work products, and QA points)

4) Project  (planning, monitoring, controlling)

Fokus manajemen perangkat lunak, tidak melulu pada "product" atau working-software itu sendiri. Selain itu, diperlukan fokus untuk mengelola People (yakni semua yang terlibat dalam pengembangan perangkat lunak); Process (atau bisa disebut sebagai kerangka kerja, metodologi yang digunakan dalam mengembangkan perangkat lunak) serta Project (yang dapat dipahami sebagai aktivitas perencanaan, pengawasan dan pengendalian).

Terkait fokus manajemen PEOPLE; maka isu yang harus diperhatikan adalah bagaimana berkomunikasi. Pengalaman saya dalam mengembangkan perangkat lunak, maka semakin banyak stakeholders (dan tim pengembang) maka semakin besar juga bias dalam saluran komunikasi standar antar stakeholders (dan tim pengembang). Dalam berkomunikasi standar, kita menggunakan bahasa, namun demikian kadang ditemui, arti dan makna bahasa tertentu, sering dipahami berbeda. Isu ini akan mencuat jika tim pengembang terdiri dari anggota tim lintas generasi (perbedaan umur yang signifikan), kultur budaya yang berbeda serta lintas organisasi (atau lintas departemen). Diperlukan sebuah mekanisme komunikasi yang handal untuk menjamin saling pengertian antar tim pengembang. Tentu saja, secara pribadi, saya sangat menyarankan untuk menggunakan mekanisme: "tatap muka".

Terkait fokus manajemen PRODUCT, maka isu yang muncul biasanya adalah "scope creep", atau bertambahnya (berubahnya) fitur aplikasi. Scope creep muncul dari stakeholders, user dan tim pengembang sendiri. Mengatasi hal ini, bisa dengan sebuah kesepakatan formal mengenai fitur-fitur aplikasi yang dikembangkan. Atau jika terjadi perubahan, dikompensasi dengan besarnya cost pengembangan aplikasi. Isu lainnya yang penting juga adalah masalah kualitas perangkat lunak yang dihasilkan. Aktivitas pengujian perangkat lunak harus benar-benar dilakukan dan terdokumentasi dengan baik. Tidak bisa hanya sekedar melakukan Uji Acceptance; tapi juga HARUS melakukan uji teknis (dalam beberapa tipe uji perangkat lunak). Stakeholders harus memahami bahwa satu-satunya cara menjamin kualitas perangkat lunak adalah dengan melakukan uji perangkat lunak.

Terkait fokus manajemen PROCESS, maka isu yang harus diperhatikan adalah dokumentasi perangkat lunak. Pada dasarnya perangkat lunak itu adalah algoritma program yang menjalan proses bisnis tertentu, mengolah data dan DOKUMENTASI. Dokumentasi perangkat lunak, bukanlah sekedar Panduan Instalasi atau Panduan Menggunakan Aplikasi, tapi juga menyangkut setiap proses pengembangan perangkat lunak yang dilakukan. Hal ini penting untuk kepentingan manajemen proyek dan terlebih untuk kepentingan pemeliharaan perangkat lunak itu sendiri.