INTRODUCTION TO
SOFTWARE ENGINEERING
Session I
SE Layers
What is Software Engineering?
• Many Definitions
– “… the establishment and use of sound engineering
principles in order to obtain economically software that is
reliable and works efficiently on real machines.” (Bauer
1969)
– “The application of science and mathematics by which the
capabilities of computer equipment are made useful to
man via computer programs, procedures, and associated
documentation.” (Boehm 1981)
– “The application of a systematic, disciplined, quantifiable
approach to the development, operation and maintenance
of software; that is the application of engineering to
software.” (IEEE 1993)
– Designing, building and maintaining large software
systems in a cost-effective way.
Why bother with Software
Engineering?
• Many very successful projects don’t use software engineering,
e.g.
– early Microsoft
– ID Software’s Doom
– Sausage’s Hotdog
BUT they are often not repeatable
• Many more projects fail because they don’t use software
engineering. Failures occur because:
– of the size of the project relative to previous efforts
– key personnel have left
– of failure to understand requirements
– the project delivers, but lacks the required quality
– of the introduction of new technology
– of many, many other reasons
Product and Process
• Both are key aspects in software engineering
• We move from an emphasis on product to
process, and back and forth
– Structured programming - Product
– Structured analysis and design - Process
– Data encapsulation (OO languages) - Product
– Capability Maturity Model/ISO9000 - Process
– Next step?
• We need to be able to deliver quality software
products to our customers with a consistent,
well-managed and cost-effective process
• Product and process are not a dichotomy
The Software Product
• Is not the same as a hardware product
– Software is developed or engineered, it isn’t manufactured
like a personal computer
– Software doesn’t wear out
– Most software is custom-built, rather than being
assembled from existing components
• A software product should
– perform the required function
– be reliable
– be maintainable
– be efficient
– have an appropriate user interface
– have an appropriate lifetime
A good software product?
The Software Product
• Is composed of
– Programs
– Data
– Documentation
• requirements, analysis & design documents, walk-through
minutes, test plan, user manuals, etc.
often referred to as the “software configuration”
• Two main types of product
– Generic - eg. Windows, Macintosh application software
– Bespoke - Systems created for specific application areas
• Most software expenditure is generic
• Most software development effort is bespoke
The Software Process
• The set of activities and associated results which
produce a software product
• The sequence of steps required to develop and
maintain software
• Sets out the technical and management
framework for applying methods, tools and
people to the software task
• Definition:
– The Software Process is a description of the process
which guides software engineers as they work by
identifying their roles and tasks.
Characteristics of a good process
• Understandability
• Visibility
• Supportability
• Acceptability
• Reliability
• Robustness
• Maintainability
• Rapidity
Two questions
• Is there a right process for software
engineers to adopt?
• Will having a good process
guarantee a good product?
When do we need process?
• We always have some process!
• The larger the project, the greater the need
for a formal process
• Complexity of building a system when related
to size is not linear.
Size Effort Errors
Required after
release
Gigatron 5,000 1 25
Gigatron 2 50,000 20 375 (15
Deluxe times
Determining Process
• Several Schemes
• US Department of Defense use the Project
Formality Worksheet [McC1997]
• Projects rate between 12 (minimal formality)
to 60 (maximum formality)
• Most student projects are well under 20 and
require very minimal formal process to be
successful
Steps in a Generic Software Process
• Project Definition
• Requirements Analysis
• Design
• Program Implementation
• Component Testing
• Integration Testing
• System Testing
• System Delivery
• Maintenance
Process Activities (1)
• Project Definition
– States the purpose of the project
– Makes initial decision on political and technical
feasibility of the project
• Requirements Analysis
– High level definition of the functionality of the
system, primarily from the point of view of the users
• Design
– Looks at the software requirements of the system and
the architecture of the system
– Lower level design activities - data structures,
interface representations, procedural (algorithmic)
details
Process Activities (2)
• Program Implementation
– Writing or generating the code to build the system
• Component Testing
– Testing of the individual components while they are
being built and after they have been completed
• Integration Testing
– Testing of the way individual components fit together
• System Testing
– Testing of the whole system usually in concert with
the users (acceptance testing)
Process Activities (3)
• System Delivery
– Implementation of the system into the working
environment and replacement of the existing
system
• Maintenance
– Corrective
– Adaptive
– Perfective
References
• [Pre2000] Pressman, R., Software Engineering:
A Practitioner's Approach, McGraw-Hill, 2000,
(Chapters 1 and 2).
• [McC1997] McConnell, S., Less is More: Jump-
Start Productivity with Small Teams, Software
Development, October 1997, pp. 28-34.
http://www.stevemcconnell.com/articles/art06.htm
TUGAS
• Membentuk kelompok @2 org, menentukan sistem yang ingin
dikembangkan.
• Bermain peran developer- calon user dan belajar berkomunikasi
dan berinteraksi dalam tahap komunikasi, untuk memahami:
– Judul dan lingkup sistem serta tujuannya
– sistem yang berjalan (pelaku, proses, data/informasi)
– Permasalahan sistem yang berjalan dan prospek pengembangan
– Sistem yang diusulkan
• Mempresentasikan hasil pengumpulan data dan analisis kebutuhan
dalam bentuk deskriptif (+ gambar untuk sistem yang berjalan) dari
kelompok partner