Rekayasa Perangkat Lunak Kuliah 2
Outline of this presentation Attributes of Good Software Why Software Engineering ? What is Software Product ? Software Myths 2
Attributes of Good Software Maintainability Dependability Efficiency Usability 3
Attributes of Good Software Maintainability more than 50% of software cost is due to maintenance Easy to maintain – Good Documentation – Good Design 4
Attributes of Good Software Dependability Reliability, – Do the Right Process Security, – Good Thread Protection Safety – No Surprise – On-line & Off-line Help 5
Attributes of Good Software Efficiency Memory, – Small Memory Usage CPU time – Efficient cycle time Storage – Minimum Amount of Storage 6
Attributes of Good Software Usability User Interface – Familiar Look – Nice & Complete – Incorporate Message Alert Documentation – User Guide » Thorough & Complete 7
Why Software Engineering ? Analogy with bridge building: – Over a stream easy, one person job – Over River Severn … ? (the techniques do not scale) 8
Why Software Engineering ? 10...to get away from ad hoc and unpredictable software development towards a systematic, understood one …
What is Software Product ? 11 a general market Software products may be developed for : or may be developed for a particular customer
What is Software Product ? Software products may be – Generic (for general market) developed to be sold to a range of different customers e.g.Excel or Word or Visual Basic etc 12
What is Software Product ? Software products may be – Bespoke / Custom (for particular customer) developed for a single customer according to their specification. e.g.……….. 13
New software can be created by – Developing new programs, or – Reusing existing software or – Configuring generic software systems 14
New software can be created by – Developing new programs, Starting from scratch one full development cycle 15
New software can be created by – Reusing existing software Not starting from scratch Using own working software Modifying & Adapting with the New Requirement 16
New software can be created by – Configuring generic software systems Not starting from scratch Using on the shelve software Tailoring with the requirement 17
Software Myths Wrong Assumption From – Management Cost - Schedule - Quality – Customer Use – Developer Build 18
Management Myths Myth – Standard and procedures are already exist for producing software Fact – Standards are rarely used – Developers rarely know about them – Standards are often out-of date and incomplete 19
Management Myths (cont.) Myth – State-of-the-art tool are the solution Fact – A fool with a tool is still a fool 20
Management Myths (cont.) Myth – If we get behind schedule, we can always add more peoples and thus catch up Fact – Software development is not a mechanistic process like manufacturing. – Adding people to a late software project makes it later. – What about Training - Integration - Social Aspect 21
Developer Myth Myth – The only deliverable is the working program(s). Fact – A working program is only one part of a software configuration that includes requirements and specification documents, testing information and other developmental and maintenance information. 22
Developer Myth (cont.) Myth – Once the program is written and it works, then the job is done. Fact – Between 50 and 70 percent of all effort expended on a program will be expended after it is delivered to the customer. 23
Developer Myth (cont.) Myth – Until the program is running, there is no way to assess its quality. Fact – One of the most effective software quality assurance mechanisms is the formal technical review and this can be applied from the inception of the project. 24
Customer Myth Myth – A general statement of objectives is sufficient to begin writing programs - we can fill in details later. Fact – Thorough communication between customer and developer needed 25
Customer Myth (cont.) Myth – Changes can be easily accommodated because software is flexible Fact – Changes happen as a fact of life – late changes are expensive 26