Overview of Software Engineering Principles CSCI 599 Software Engineering for Embedded Systems August 28 2001 Engineering Engineering is the application of scientific principles and methods To the construction of useful structures machines Examples Mechanical engineering Civil engineering Chemical engineering Electrical engineering Nuclear engineering Aeronautical engineering Software Engineering The term is 30 years old NATO Conferences Garmisch Germany October 7 11 1968 Rome Italy October 27 31 1969 The reality is finally beginning to arrive Computer science as the scientific basis Other scientific bases Many aspects have been made systematic Methods methodologies techniques Languages Tools Processes Software Engineering in a Nutshell Development of software systems whose size complexity warrants team s of engineers Scope multi person construction of multi version software Parnas 1987 study of software process development principles techniques and notations Goal production of quality software delivered on time within budget satisfying customers requirements and users needs Ever Present Difficulties Few guiding scientific principles Few universally applicable methods As much managerial psychological sociological as technological Why These Difficulties SE is a unique brand of engineering Software is malleable Software construction is human intensive Software is intangible Software problems are unprecedentedly complex Software directly depends upon the hardware It is at the top of the system engineering food chain Software solutions require unusual rigor Software has discontinuous operational nature Software Engineering Software Programming Software programming Single developer Toy applications Short lifespan Single or few stakeholders Architect Developer Manager Tester Customer User One of a kind systems Built from scratch Minimal maintenance Software Engineering Software Programming Software engineering Teams of developers with multiple roles Complex systems Indefinite lifespan Numerous stakeholders Architect Developer Manager Tester Customer User System families Reuse to amortize costs Maintenance accounts for over 60 of overall development costs Economic and Management Aspects of SE Software production development maintenance evolution Maintenance costs 60 of all development costs 20 corrective 30 adaptive 50 perfective Quicker development is not always preferable higher up front costs may defray downstream costs poorly designed implemented software is a critical cost factor Relative Costs of Fixing Software Faults 200 30 10 1 Requirements 2 Specification 3 Planning 4 Design Implementation Integration Maintenance Mythical Man Month by Fred Brooks Published in 1975 republished in 1995 Central argument Large projects suffer management problems different in kind than small ones due to division in labor Critical need is the preservation of the conceptual integrity of the product itself Central conclusions Experience managing development of OS 360 in 1964 65 Conceptual integrity achieved through chief architect Implementation achieved through well managed effort Brooks s Law Adding personnel to a late project makes it later Software Development Lifecycle Waterfall Model Requirements Design Implementation Integration Validation Deployment Software Development Lifecycle Spiral Model Determine objectives alternatives constraints Plan next phases Evaluate alternatives identify resolve risks develop prototypes Develop verify next level product Requirements Problem Definition Requirements Specification Difficulties determine exactly what the customer and user want develop a contract with the customer specifies what the software product is to do client asks for wrong product client is computer software illiterate specifications are ambiguous inconsistent incomplete Verification extensive specification reviews with the customer identify ambiguity inconsistency incompleteness ascertain feasibility testability develop system acceptance test plan Architecture Design Requirements Specification Architecture Design Difficulties architecture decompose software into modules with interfaces design develop module specifications algorithms data types maintain a record of design decisions and traceability specifies how the software product is to do its tasks miscommunication between module designers design may be inconsistent incomplete ambiguous Verification design inspections to establish conformance to requirements check module interactions develop integration test plan Architecture vs Design Perry Wolf 1992 Architecture is concerned with the selection of architectural elements their interactions and the constraints on those elements and their interactions necessary to provide a framework in which to satisfy the requirements and serve as a basis for the design Design is concerned with the modularization and detailed interfaces of the design elements their algorithms and procedures and the data types needed to support the architecture and to satisfy the requirements Implementation Integration Design Implementation Difficulties implement modules verify that they meet their specifications combine modules according to the design specifies how the software product does its tasks module interaction errors order of integration may influence quality and productivity Verification code reviews to establish conformance to requirements design check module interactions develop unit test plan focus on individual modules test on unit integration and acceptance test plans Component Based Development Develop generally applicable components of a reasonable size and reuse them across systems Make sure they are adaptable to varying contexts Extend the idea beyond code to other development artifacts Question what comes first Integration then deployment Deployment then integration Different Flavors of Components Third party software pieces Plug ins add ins Applets Frameworks Open Systems Distributed object infrastructures Compound documents Legacy systems Verification and Validation Analysis Static Science Formal verification Informal reviews and walkthroughs Testing Dynamic Engineering White box vs black box Structural vs behavioral Issues of test adequacy Deployment Evolution Operation Change Difficulties maintain software during after user operation determine whether the product still functions correctly rigid design lack of documentation personnel turnover Verification extensive reviews to ensure correct changes
View Full Document
Unlocking...