Pertemuan 1 Software Engineering: The Product
Aturan Kelas Semua gadget (handphone, Pager, BB, PDA) dinonaktifkan dan tidak digunakan selama di kelas. SMS, BBM dan telephone di luar kelas Toleransi keterlambatan 30 menit. Jika dosen sudah menutup pintu, mahasiswa dilarang mengisi daftar hadir Kehadiran mahasiswa mengikuti aturan Fakultas yaitu 75% kehadiran dosen Menitipkan tanda tangan kehadiran dan menyalin tugas diberi sangsi nilai “E” Dilarang mengobrol selama dosen memberi bahan ajar dan rekan-rekan presentasi tugas Berpakaian pantas dan rapi, tidak menggunakan sandal/semi sepatu
Aturan Penilaian •
UTS: 30% •
•
UAS: 40% •
•
Sifat Closed Book, Soal Essay dan Studi Kasus
Sifat Closed Book, Soal Essay dan Studi Kasus
KAT: 30% •
• • •
Quiz : 20 % • Dilakukan tiap minggu 30 menit sebelum kuliah berlangsung • Soal pilihan ganda/essay • Sifat quiz closed book/file Tugas Mingguan : 15% Tugas Besar Tim : 60% Kehadiran :5%
UTS KAT UAS
Tugas Proyek Per Kelompok •
Buat kelompok @ maksimal 5 orang (Project Manager, System Analyst, System Designer, 2 orang Programmer)
•
Memilih salah satu topik pengembangan perangkat lunak yang disediakan Dosen, tidak boleh ada kelompok yang mengerjakan P/L yang sama baik di dalam maupun antar kelas (topik yang dapat dipilih lihat slide berikutnya)
•
Lakukan semua tahapan pengembangan sistem mulai dari pembuatan SRS (software requirement spesification), analisis, desain, implementasi dan pengujian sistem
•
Membuat makalah, bahan presentasi dan perangkat lunak hasil pengembangan untuk mempresentasikan tugas
Topik untuk Tugas Besar (1/4) •
Aplikasi untuk Toko : pembelian, penjualan, keuangan
•
Aplikasi untuk Pabrik : pengadaan, produksi, manajemen barang di gudang, penjualan, keuangan
•
Aplikasi untuk Perbankan : simulasi ATM, teller
Topik untuk Tugas Besar (2/4) •
Aplikasi untuk Sekolah/Universitas : penjadwalan, penilaian, pembelajaran
•
Aplikasi untuk Bioskop
•
Aplikasi penerapan kepakaran/kecerdasan buatan
•
Aplikasi Game : single player, multi player, online, offline
•
Aplikasi Kamus : berbagai bahasa
Topik untuk Tugas Besar (3/4) •
Aplikasi untuk Perpustakaan : pengadaan, peminjaman, pengembalian, pelaporan
•
Aplikasi untuk Restoran/Rumah Makan
•
Aplikasi penerapan teori khusus : datamining, information retrieval
•
Aplikasi jaringan komputer & sekuriti
Topik untuk Tugas Besar (4/4) •
Aplikasi internet/mobile : e-banking, e-learning, e-library, egovernment, e-commerce
•
Aplikasi untuk Lembaga Pemerintahan : aplikasi untuk Kantor Pos, Kepolisian, Kereta API, Pesawat Terbang, administrasi kependudukan (pembuatan KTP, KK)
Format Proposal, Kontrak dan SRS
Seluruh format proposal, kontrak dan SRS akan diberikan template terpisah dengan slide ini, kecuali untuk format laporan akhir ada di halaman slide selanjutnya.
Format Laporan/Makalah Akhir (1)
Bab 1 Pendahuluan 1.1 Latar Belakang 1.2 Tujuan 1.3 Ruang Lingkup Proyek
◦ ◦ ◦
Bab 2 Analisis 2.1 Proses Sistem (As-is System) 2.2 Flowchart Sistem (As-is System)
Bab 3 Desain Perangkat Lunak ◦
Desain Sistem
◦
Desain Basis Data
◦
DFD Level Context DFD Level Pecahan ER-Diagram Desain Tabel-tabel & Relasinya
Desain User Interface
Bab 4 Pengembangan Sistem Implementasi Basis Data Implementasi Sistem Menyeluruh Implementasi User Interface Bab 5 Pengujian Black Box White Box Bab 6 Penutup Kesimpulan Saran Optional : Manual Book
Format Laporan/Makalah Akhir (2)
Dokumen dijilid softcover hijau FIT Dokumen sudah lengkap dengan halaman cover, kata pengantar halaman daftar isi, halaman isi (bab 1-6), daftar pustaka. Di cover paling belakang diberi tempat untuk menempelkan CD/DVD untuk dokumentasi seluruh dokumen dan piranti lunak hasil proyek.
Referensi Pressman, Roger S, Software Engineering : A Practitioner’s Approach, 4th/5th Edition, McGraw – Hill, New York Pfleger, Shari L, Software Engineering : Theory and Practice, Prentice Hall
Schwalbe, Kathy, IT Project Management
General Electric Company, Software Engineering Handbook, MC Graw Hill, New York
Ian Sommerville, Software Engineering, 7th
Rencana Pertemuan •
Lihat di laman RPL1 di situs http://andiwre.itmaranatha.org
Some Questions •
What is? • • • • •
A Software Product Software Engineering A Software Process A Software Process Model CASE
•
How do you identify good software?
•
What are emergent system properties?
•
What are professional and ethical responsibilities?
•
What is a legacy system?
•
What are critical systems?
What This Picture Mean to You?
The software crisis •
Advances in hardware technologies made it possible to build powerful computers •
This allowed building of more complex and powerful software
•
Existing software development methodologies were not capable of handling such large projects.
•
Hence projects had many problems: Over budget • Late delivery • Requirements not met • Poor usability •
Software engineering •
The economies of ALL developed nations are dependent on software
•
More and more systems are software controlled •
Software is becoming pervasive
•
Software costs dominate system costs
•
Software engineering is concerned with cost-effective software development
What is Software?
Software is a set of items or objects that form a “configuration” that includes : • instructions/programs to get a desired function/performance • data structure to get information • documents of operation
What is Software? Another Definition: Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system (IEEE Standard Glossary of Software Engineering Terminology, 1990)
What is software? (Another Definition) •
Computer programs and associated documentation (plus configuration data and user training)
•
Software products may be developed for a particular customer or developed for a general market Generic (shrink-wrapped) - developed to be sold to a range of different customers • Bespoke (custom) - developed for a single customer according to their specification •
What is Software ? Software is designed and built by software engineers. Software is used by virtually everyone in society. Software engineers have a moral obligation to build reliable software that does no harm to other people. Software users are only concerned with whether or not software products meet their expectations and make their tasks easier to complete.
What is Software ? Software is both a product and a vehicle for delivering a product (information). Software is engineered not manufactured. Software does not wear out, but it does deteriorate. Currently, most software is still custom-built.
Software Characteristics •
software is engineered not manufactured
•
software doesn’t wear out, it is like an ‘aging factory’
•
software is complex
Failure Curve Failure Rate
"Infant Mortality"
"Wear Out"
Change
Actual Ideal Time
Time FAILURE CURVE FOR HARDWARE
FAILURE CURVE FOR SOFTWARE
* Software Engineering, Module 1, Richard Conn, University of Cincinnati, May 1993
Software Applications system software real-time software business software engineering/scientific software embedded software PC software AI software WebApps (Web applications)
What are the attributes of good software? •
The software should deliver the required functionality and performance to the user and should be maintainable, dependable and acceptable.
•
Maintainability •
•
Dependability •
•
Software must be trustworthy
Efficiency •
•
Software must evolve to meet changing needs
Software should not make wasteful use of system resources
Usability •
Software must be usable by the users for which it was designed
...attributes of good software (these two are not always required) •
Robustness •
•
Software should fail only under extreme conditions
Portability •
Should be possible to move from one environment to another
Software Poses Challenges How do we ensure the quality of the software that we produce? How do we meet growing demand and still maintain budget control? How do we upgrade an aging "software plant?" How do we avoid disastrous time delays? How do we successfully institute new software technologies?
New Software Challenges Ubiquitous computing • Creating software to allow machines of all sizes to communicate with each other across vast networks
Netsourcing • Architecting simple and sophisticated applications that benefit targeted end-user markets worldwide
Open Source • Distributing source code for computing applications so customers can make local modifications easily and reliably
New economy • Building applications that facilitate mass communication and mass product distribution using evolving concepts
Legacy Software Many programs still provide a valuable business benefit, even though they are one or even two decades old. These programs must be maintained and this creates problems because their design is often not amenable to change.
Legacy systems •
Socio-technical systems that have been developed using old or obsolete technology.
•
Crucial to the operation of a business and it is often too risky to discard these systems Bank customer accounting system; • Aircraft maintenance system. •
•
Legacy systems constrain new business processes and consume a high proportion of company budgets.
Legacy system components •
Hardware - may be obsolete mainframe hardware.
•
Support software - may rely on support software from suppliers who are no longer in business.
•
Application software - may be written in obsolete programming languages. (sometimes referred to as legacy system)
•
Application data - often incomplete and inconsistent.
•
Business processes - may be constrained by software structure and functionality.
•
Business policies and rules - may be implicit and embedded in the system software.
Legacy Software must be adapted to meet the needs of new computing environments or technology must be enhanced to implement new business requirements must be extended to make it interoperable with more modern systems or databases must be re-architected to make it viable within a network environment
Critical Systems •
Systems where failure causes significant economic losses, physical damage or loss of life •
Not your favourite word processor program!
Faults and failures •
Failures are a usually a result of system errors that are derived from faults in the system
•
However, faults do not necessarily result in system errors •
•
The faulty system state may be transient and ‘corrected’ before an error arises
Errors do not necessarily lead to system failures • •
The error can be corrected by built-in error detection and recovery The failure can be protected against by built-in protection facilities. These may, for example, protect system resources from system errors
Where failure could occur •
Hardware failure •
•
Software failure •
•
Hardware fails because of design and manufacturing errors or because components have reached the end of their natural life. Software fails due to errors in its specification, design or implementation.
Operational failure •
Human operators make mistakes. Now perhaps the largest single cause of system failures.
Types of critical systems •
Safety-critical systems Failure results in loss of life, injury or damage to the environment • E.g. Chemical plant protection system •
•
Mission-critical systems Failure results in failure of some goal-directed activity • E.g. Spacecraft navigation system •
•
Business-critical systems Failure results in high economic losses • E.g. Customer accounting system in a bank •
Software Evolution Process by which programs change shape, adapt to the market place, and inherit characteristics from preexisting programs Unified theory for • Law of continuing change software evolution • Law of increasing complexity •… (Lehman):
The Cost of Change 60-100x
1.5-6x 1x
Definition
Development
After release
Important Questions for Software Engineers Why does it take so long to get software finished?
Why are development costs so high? Why can't we find all errors before we give the software to our customers? Why do we continue to have difficulty in measuring progress as software is being developed?
Software Myths
Management myth : quantity of people = productivity
Customer Myths : Software is flexible to changes
Practitioner Myths : The only deliverable is the working program
Software Myths Still believed by many managers and practitioners Insidious because they do have elements of truth Every practitioner and manager should understand the reality of the software business.
Software Myths: Clients’ point of view Myths:
Reality:
•
A general statement of objectives is enough to get going. Fill in the details later.
•
Poor up-front definition of the requirements is THE major cause of poor and late software.
•
Project requirements continually change, but change can be easily accommodated because software is flexible.
•
Cost of the change to software in order to fix an error increases dramatically in later phases of the life of the software.
Software Myths: Developers’ point of view Myths: •
Once a program is written and works, the developer's job is done.
•
Until a program is running, there is no way to assess its quality.
•
Reality: •
50%-70% of the effort expended on a program occurs after it is delivered to the customer.
•
Software reviews can be more effective in finding errors than testing for certain classes of errors.
•
A software configuration includes documentation, regeneration files, test input data, and test results data.
The only deliverable for a successful project is a working program.
Software Myths: Management’s point of view Myths:
Reality:
Books of standards exist in-house so software will be developed satisfactorily.
Books may exist, but they are usually not up to date and not used.
Computers and software tools that are available in-house are sufficient.
CASE(**) tools are needed but are not usually obtained or used.
We can always add more programmers if the project gets behind.
"Adding people to a late software project makes it later." -- Brooks
What is software engineering? •
An engineering discipline which is concerned with all aspects of software production
•
Engineering discipline Discover solutions by applying theories, methods or other mechanisms. • Work within constraints •
•
All aspects of software production Software development (technical processes) • Project management • Development of supporting tools, methods and theories •
Professional And Ethical Responsibility •
Software engineering involves wider responsibilities than simply the application of technical skills.
•
Software engineers must behave in an honest and ethically responsible way if they are to be respected as professionals.
•
Ethical behaviour is more than simply upholding the law.
* Software Engineering 7th ed, Ian Sommerville
Issues of professional responsibility •
Confidentiality •
•
Engineers should normally respect the confidentiality of their employers or clients irrespective of whether or not a formal confidentiality agreement has been signed.
Competence •
Engineers should not misrepresent their level of competence. They should not knowingly accept work which is outside their competence.
Issues of professional responsibility •
Intellectual property rights •
•
Engineers should be aware of local laws governing the use of intellectual property such as patents, copyright, etc. They should be careful to ensure that the intellectual property of employers and clients is protected.
Computer misuse •
Software engineers should not use their technical skills to misuse other people’s computers. Computer misuse ranges from relatively trivial (game playing on an employer’s machine, say) to extremely serious (dissemination of viruses).
