Yang ini cuma lanjutin yang kmrn. yaitu kasi update.php untuk update isi database sesuai yg diisikan. field2 yg ada sudah terisi dgn data di database.
setelah di teken update lgsg databasenya di update.
Senin, 26 April 2010
Minggu, 25 April 2010
PR ASISTENSI 29 APRIL
Pertama bikin login biasa, trus di cari di table tpegawai cocok ap nda. klo cocok baru bisa lanjut k katalog.php.
Masuk ke katalog. kita bisa kurangi stok barang dgn teken tombol add di msg2 item.
setelah teken tombol add disblh field yg diisi, stok item tsb akan berubah. stok yang berubah hanya yang item yang tombolnya diteken. conto klo semua field diisi tapi yang diteken cuma tombol nya meja belajar, stok yang berkurang hanya stok meja belajar. yg lain tetep.
trus kan shrusnya ada 5 item. kita buat paging tiap page pny 3 item saja.
semua variable stok yang dikurang-kurangi masih ada di variable session. tidak mempengaruhi database.
trus buat tombol untuk menyimpan perubahan dan mengupdate database.
waktu tombol save diteken, ada 3 table yang perlu diupdate. xg pertama table tbarang. table tbarang akan mengupdate value dari stok masing2 barang menjadi sama seperti stok pada variable session yang ada.
trus tabel hpengeluaran itu di insert kode keluar diambil dari kode keluar terakhir+1,date/time saat mengupdate, user yang mengupdate.
tabel dpengeluaran diinsert dengan kode keluar diambil dari kode keluar terakhir+1,kodebarang yang dikerluarkan, jumlah item yang dikeluarkan.
Ini link sql dan doc soal. + screenshot sourcecode saya. :D
Kamis, 15 April 2010
Rabu, 14 April 2010
Tugas SAD
Systems Analysis and Design
Jum’at tgl 16 Apr, kita diminta kumpulkan proposal ttg bisnis applikasi apa yang mau kita analisa. Ini DOC yg bu yunmel kasi.
Assignment Specifications
Assignment Description
1. You are required to analyse and design one common business application in one of the following systems:
- a grocery store (sales and purchase system)
- a book/computer/DVD inventory management and sales system
- a banking (financial) system
- a travel agent
- a real estate company
- etc. (must be approved by your supervisor)
2. You are required to develop and submit three documents:
- software project plan
- software requirements specification document
- software design document
Deliverables and Dates
Assignment 1: Submit a CD-R containing Project Plan Document and Software Requirements Specification Document in week 8.
Assignment 2: Submit a CD-R containing Revised Project Plan Document, Revised Software Requirements Specification Document, and Software Design Document in week 13.
Project Presentation: You must present the project during week 13-14.
Marking Scheme
This assignment worth 30% from the final mark.
A typical project plan document would have the followings:
· A short introduction to the organisation / system (history, achievements)
· A description of the current system, or the “current way of doing things”.
· A section about basic problems and limitations as faced by the customer’s point of view.
· A proposal of the new system, containing the objectives of the new system (should be made relevant to the basic problems and limitations of the current system), and a description of the new system, with an identification of the major modules of the new system.
· The initial new system requirements (also known as the Initial Specifications). This in effect is preliminary statement in precise terms what exactly the project team recommends the proposed system be able to do.
· A section explaining the benefits of the implementation of such a system.
· The hardware and software equipments to be used in the development, and also hardware and software equipments of the target platform as used by the system.
· A cost/benefit study. The cost/benefit study should not simply be a theoretical presentation but preferably contain a breakdown of monetary costs and expected benefits of the proposed system, payback periods and Return of Investment (ROI).
· A Gantt chart indicating the planned progress for the project group. The Gantt chart should be reasonably detailed The Gantt chart in the proposal should be broken into a week by week basis. For example, the Analysis phase can be broken into the following sub-activities:
Ø Preliminary survey
Ø Collection of relative information
o Interview phase
o Observation phase
o Hard-data investigation
Ø Consolidation of information
Ø Development of Data Flow Diagram
Ø DFD Analysis
Ø Requirement Specification Documentation
A typical software requirements specification document would have the followings:
· Introduction: a broad introduction about the initiation of the project and a brief description of the organisation in question.
· Fact-Finding: This section should include the following items:
Ø Justification of fact-finding techniques used. The justification should be made relevant to the organisation and/or system characteristics, and not based on general fact-finding technique characteristics.
Ø Completeness and quality of fact-finding, for example: number of persons interviewed, quality of questions asked, appropriateness of observations. Copies of the fact-finding documentation, i.e. interview sheets, must be included into the appendix of this document.
Ø Analysis of results: The production of conclusive observations supported with the raw data from fact-finding.
· Description of the Current System: A detailed description of the system as it is. This section should include the following items:
Ø Narrative (input, output, processes) supported by diagrams (e.g. system breakdown structures), charts (e.g. organisational charts), tables, etc.
Ø Detailed DFDs (context diagram, level 0, and at least level 1 diagram).
Ø Problems and limitations of the current system from the detailed study.
Ø Scope and constraints (such as budgetary, technological or other resource constraints).
· Requirements Specification: This section is concerned with a detailed description of what the proposed system would be required to fulfil. The requirements should be presented as an enumerated list of requirements in fairly precise languages.
A typical software design document would have the followings:
· Description of new system: This section should include a narrative supported by necessary illustrations and DFDs of the new system to be developed.
· Database Design: Entity-Relationship Diagram, Data Dictionary, Normalisation, Logical and Physical Design of the database should be presented here.
· Architectural Design: Program structure information should be presented here. For example, the breakdown of a system into its sub-component parts and modules.
· Interface Design: Screen and Report design information should be presented here. The screen and report captures must be preceded by a section explaining the design of screens and reports, including the justification of the design (such as color scheme, font sizes, etc.).
· Procedural Design: Based on the program structure, procedural information for each module should be presented here. You may use pseudo code or flowcharting techniques.
Please note that the software design document acts as a ‘blue-print’ of the software that will be used by the programmers to construct the software. It must not have any ambiguity that may lead to misunderstanding with the programmers.
Rabu, 07 April 2010
Minggu, 04 April 2010
Langganan:
Komentar (Atom)