Definitions of Software Engineering Establishment and use of
Definition(s) of Software Engineering Establishment and use of sound engineering principles to obtain economically software that is reliable and works on real machines efficiently. (Fritz Bauer) Software Engineering Introduction 1
Definition(s) of Software Engineering (cont’d) (i) Application of a systematic, systematic disciplined, quantifiable approach to the development, operation and maintenance of software; that is, the application of engineering to software. (ii) The study of approaches as in (i). (IEEE 93) Software Engineering Introduction 2
• By “systematic” we mean: Following a well-defined sequence of activities, - in which desired outputs (deliverables) are well-defined - by using well-defined inputs (i. e. documented syntax, semantics, context and other relevant properties of the input) - in a well-defined process (e. g. using organizational standards for interprocess communication, data formats, error handling etc. ) - whose outputs are in turn used similarly as inputs in subsequent process(es), - until the final output is achieved, - and where the correctness of the output is verifiable. Note: The “inputs” and “outputs” most often refer to requirements, software specifications, the software itself, documentation, test inputs/outputs and similar software artifacts. Back Software Engineering Introduction 3
By “disciplined” we mean: • Each process is followed using organizational principles (e. g. who manages whom, who is responsible for what? ), • Intermediate results are carefully documented, as well as final results, • Actions are traceable as to their causes, individuals involved, time of occurrence and circumstances. Back Software Engineering Introduction 4
By “quantifiable” we mean: • The size and extent of the required effort (size of output code, data, documentation, manpower, duration, budget for development, expected error rate and user support) are predictable within justifiable and acceptable bounds Software Engineering Introduction 5
What SWE is not: • Just “programming” or “coding” • System engineering (in a broad sense) although software engineers may be called upon to participate in system engineering analyses • Software salesmenship although they may be called upon to help analyze customer needs Software Engineering Introduction 6
Why Do We Need SWE? To make the production of software • easier • more disciplined and predictable • more economical. • Back Software Engineering Introduction 7
Evolution of Software Technology • • • Operating systems Languages Development tools Database and networking technology Project management tools Software Engineering Introduction 8
Evolution of machine architecture • • Improvement of machine instruction sets Invention mass storage devices Machine interrupt schemes Much larger physical memories Virtual memory (paging) Cache memory Fault-tolerant computing Parallel and multi-processing Software Engineering Introduction 9
Evolution of Systems Interconnection • Local area networking (peer-to-peer and hierarchical connection, servers) • Wide area networking (dial-up and fixed connections) • Networking architecture • Communication protocols Software Engineering Introduction 10
Database Systems • From simple sequential “files” to “databases” • Indexed files • Hierarchical databases • Network-style databases • Relational databases • More recently, object-oriented databases • Database management systems Software Engineering Introduction 11
Decreasing Hardware Costs • • Ever smaller and faster components More reliable Requiring less energy More easily replaceable Software Engineering Introduction 12
Increasing Demand • • • Improved user interfaces Cheaper and faster machines Increase in application areas Improved connections Most recently the Internet! Software Engineering Introduction 13
Differences between Software Engineering and Hardware Engineering • Software is developed or engineered, not manufactured. • Software doesn’t wear out (in the usual sense). It is updated or replaced with a new version. • Most software tends to be custom-built eventhough there is a movement toward componentbased assembly. Software Engineering Introduction 14
Hardware Failure Pattern “Bathtub Curve” Software Engineering Introduction 15
Software Failure Pattern Software Engineering Introduction 16
Examples of Application Areas • System software (Operating systems, compilers, databases, graphics packages, communication. . . ) • Real-time software Interacts with external events Has tight timing requirements Requires high-security, reliability and availability Often mission-critical (can not be allowed to fail) Software Engineering Introduction 17
Application Areas (cont’d) • Business Software Ranging from simple to very complex Requiring its own expert knowledge Very large files Needs telecommunication, devices like point-of-sale (POS) terminals Highly organized computer organization and personnel (esp. in large companies) Very detailed records covering long periods Software Engineering Introduction 18
Engineering and Scientific Software • Complex formula evaluation • Very high accuracy • Interaction with data collection devices (e. g. Sensors) often at high speeds • High resolution graphic displays of large amounts of data • Parallel and multi-processor applications Software Engineering Introduction 19
Embedded Software • Software embedded in non-computer devices (e. g. cars, planes, cell phones, home appliances such as refrigerators) through special-purpose processors • Must be resistant to failures, tough climactic conditions, rough handling • Often optimized to require least memory and still maintain speed Software Engineering Introduction 20
Military Software • • • Often real-time Engineering/scientific Including embedded components High-technology (communications) High security and error control (reliability) Software Engineering Introduction 21
Video Game Software • • • Graphic and artistic content Video-type action Very high timing requirements High-sped user interaction Graphics and sound integrated Software Engineering Introduction 22
Artificial Intelligence Software Involves: Problem solving, Complex symbolic programming (e. g. pattern recognition, theorem proving, virtual reality concepts, game playing etc. ) Physical system control (e. g. Robotic arm-leg movement) Vision, sound/voice recognition. . . Software Engineering Introduction 23
Web-based Applications • General public information (news, info about organizations and society) • Business-to-consumer communication (product promotions, sales) • Business-to-business communication • Electronic mail • “Surfing” • Seach engines Software Engineering Introduction 24
Building Blocks of Software Engineering Tools Methods Process QUALITY FOCUS Software Engineering Introduction 25
The Generic SWE Approach • What is the problem to be solved? -- The most important question of all. . . -- Do we have sufficient detail ? -- Do we really know what the customer wants? -- Does he agree that’s what he wants? Software Engineering Introduction 26
More questions. . . • How will the solution be realized? How shall we test the solution once it is constructed? How shall we maintain the system and support the users in the short and long terms? Software Engineering Introduction 27
The Software Development Process (also called the Software Process) is the process used to answer the above questions, dealing with: • Definition of the problem • Analysis of the problem • The conception and development of a design • Implementation of the design Software Engineering Introduction 28
The Software Development Process (cont’d) • • • Testing Documentation User Training (if required) Maintenance and support Enhancement of the product (if required).
The Software Development Process (cont’d) The sequence and extent of activities needed to carry out the above process varies depending on: • How well the user (customer) understands his own needs • How well the developers know the application area
The Software Development Process (cont’d) • Resources available for the project (time, technology, money, people) • The type of project (internal/external, level of secrecy, amount of documentation, user support required etc) • The developer organization. . . And many other factors Software Process Models 31
- Slides: 31