Software Engineering Issues Software Engineering Concepts System Specifications Procedural Design Object-Oriented Design System Testing

Software Engineering Software crisis: –Arose from the rapid increase in the size and complexity of computer applications. Software engineering: –Evolved in response to the problems of cost, productivity, and reliability of large and complex software systems. –Definition: The application of engineering (systematic, disciplined, quantifiable) approach to the development, operation, and maintenance of software

Waterfall Software Life-Cycle Model What to do How to do Look at the system from the point of view of the end user Written from the point of view of system developers and programmers Outlines the most significant characteristics, the most important data structures and algorithms, modules or objects Coding and preliminary testing Several levels of testing for individual parts, communication between the parts, and the entire system Corrective, perfective, adaptive, and enhancement maintenance

System Specifications The specifications –must contain a complete description of all of the functions and constraints of the desired system, the performance needed from the system, and the interaction between the software and the users –must be clearly and precisely written –must be consistent –contain all of the information needed to write and test the software

Sample Specifications Format of the input Lexical rules for labels Content of the input Context-dependent restrictions Implementation restriction Form and content of the output Output condition Constraints on the output values Efficiency Ease of use Reliability

Decision Table Specification for Combinations of Conditions

Error Conditions Effective handling of error conditions is essential to the creation of a usable software product. –Ignore the error and continue normally –Abort or halt with no output –Issue an error message and continue processing A program should not “crash” when presented with any input –Garbage In---Meaningful Error Messages Out

Data Flow Diagrams

Top-Down Design of Data Flow Diagram

Principles of Modular Design Meet the system specifications Easy to implement, understand, and maintain Have high cohesion within a module Have low coupling between different modules

Modular Design as a Partitioning of Data Flow Diagram

Minimization of Coupling between Modules

Modularized Assembler Design

Calling Structure for Modules

Parameters and Calling Sequence for Modules

Object-Oriented Design of an Assembler

System Testing Unit testing –Individual modules are tested in isolation from the rest of the system –Black box testing Test cases are generated from the specifications for the module –White box testing Test cases are designed that force the module through certain statements Integration testing –Interfaces between modules are tested via an incremental approach Bottom-up ordering Top-down ordering System testing –Entire system are tested to verify that it meets all of the requirements and specifications –Alpha testing Performed by the organization that developed the system, before it is released to any outside users. –Beta testing Placing the system into actual use in a limited number of environments –Acceptance testing Performed by the customers to decide whether or not to accept delivery of the system

Bottom-Up Testing Bottom-up testing begins with passive objects that do not invoke methods on other objects. The sequence continues with other objects that invoke methods only on objects that have already been tested. It is necessary to simulate the remainder of the system by writing test driver program for each module.

Top-Down Testing Modules are unit tested and integrated into partial systems beginning at the highest level of the hierarchical structure. During the top-down testing, we must simulate the presence of lower-level modules by writing stubs.