CMSC 435: Sof tware More Resources Engineering Sect ion 0101 Atif - PDF document

CMSC 435: Sof tware More Resources Engineering Sect ion 0101 • Atif M. Memon (atif @cs. umd.edu) • Class TA • 4115 A. V. Williams building – Qing Xie • Phone: 301- 405- 3071 – qing@cs. umd.edu • Of f ice hours – Of f ice location – . Tu. Th. (10:45am- 12:00pm & 4:30pm- • AVW 4122 5:30pm) • Don’t wait, don’t hesitate, do – Of f ice hours communicate!! • Wed (9:00am-11:30am) – Phone • Course page – E- mail – www. cs. umd.edu/ ~atif / teaching/ spring2006 – Of f ice hours How Cars are Engineered (A I n Pictures!! simple view) • User requirements – Engine power, all- wheel, seat ing, comf ort , MP3 player!! • Detailed design – Blueprints, design documents • Test design – Simulation, protot yping • Develop parts (components) – Test each component – Component s may be reused – Mass produced • Assemble the car – Test the car • Fr ont / side cr ash t est s • St abilit y t est s – Usabilit y testing • Feedback f r om dr iver s/ passenger s Similar Techniques Used by But Seriously Builders: Bridges • Features of many LEGO parts – Modularity – Reusability • Each part can be used in dif f erent places and ways – Flexibility of design – Compatibility • Wit h ot her LEGO set s • Building- blocks 1

Detailed Design and More Det ailed Design and Specif ications Specif ications Galvanized Bridge Wire for Parallel Wire Bridge Cables. Recommended diameter .196 inch. Galvanized Bridge Strand--consists of several bridge wires, of various diameters twisted together. Galvanized Bridge Rope--consists of six strands twisted around a strand core. Detail of Main Cable and Cable Band. The wrapping wire is omitted at the right for clarity. Note the closed construction and aluminum fillers. Parallel Wire Cable Tacoma Narrows Bridge Back to Sof tware Disaster • Sof tware uses some of the most complex structures ever designed • Need to apply/ develop engineering principles to/ f or sof tware • Sof tware engineering is concerned with theories, methods and tools f or prof essional sof tware development A Few Facts About Sof tware I mportant: Team Work Today • Most sof tware is developed • Sof tware costs of ten dominate – By teams of system costs. • Designer s – The costs of sof tware are of ten • Pr ogr ammer s • Manager s greater than the hardware cost • Social skills • Sof tware costs more to maintain – Trust other team members than it does to develop. • They will develop sof t war e component s t hat you may use – For systems with a long lif e, • Management skills maintenance costs may be several – Schedules times development costs – Work distribution – Budget 2

Costs I nvolved We will Engineer Sof tware • Typically • But what is sof tware? – 60% of costs are development costs, – Computer programs and – 40% are testing costs. – Associated documentation – For custom sof tware, evolution costs of ten exceed development costs • Sof tware products may be • Costs vary depending on the type of developed f or system being developed and the – A particular customer or requirements of system attributes such as perf ormance and system reliability – A general market • Distribution of costs depends on the development method that is used Role of a Sof tware Engineer Attributes of Good Sof tware • Should deliver the required f unctionality • Sof tware engineers should adopt a and perf ormance systematic and organised approach • Maintainability to their work and use appropriate – Sof tware must evolve to meet changing needs tools and techniques depending on • Dependability the problem to be solved, the – Sof tware must be trustworthy development constraints and the • Ef f iciency resources available – Sof tware should not make wastef ul use of system resources • Usability – Sof tware must be usable by the users f or which it was designed Sof tware Processes Sof tware Process Models • What is a Sof tware Process? • A simplif ied representation of a sof tware process, presented f rom a specif ic perspective – A set of activities whose goal is the • Examples of process perspectives are development or evolution of sof tware – Workf low perspective • Some Activities: • sequence of act ivit ies – Specif ication – Data- f low perspective • what t he syst em should do and it s development • inf or mat ion f low const r aint s – Role/ action perspective – Development • who does what • pr oduct ion of t he sof t war e syst em • Generic process models – Validation – Waterf all – Evolutionary development • checking t hat t he sof t war e is what t he cust omer want s – Formal transf ormation – Evolution – I ntegration f rom reusable components • changing t he sof t war e in r esponse t o changing demands 3

Generic Sof tware Process Waterf all Model Models • The waterf all model Requirements Requirements Def inition – Separate and distinct phases of specif ication Def inition and development System & • Evolutionary development System & Sof tware Design Sof tware Design – Specif ication and development are interleaved • Formal systems development I mplementation I mplementation – A mathematical system model is f ormally & Unit Testing & Unit Testing transf ormed to an implementation • Reuse- based development I ntegration & I ntegration & System Testing – The system is assembled f rom existing System Testing components Operation & Operation & Maintenance Maintenance Waterf all Model Problems Evolutionary Development • I nf lexible partitioning of the • Exploratory development project into distinct stages – Objective is to work with customers and to evolve a f inal system f rom an • This makes it dif f icult to respond initial outline specif ication. Should to changing customer requirements start with well- understood • Theref ore, this model is only requirements appropriate when the requirements • Throw- away prototyping are well- understood – Objective is to understand the system requirements. Should start with poorly understood requirements Evolutionary Development Evolutionary Development Concurrent • Problems Activities – Lack of process visibility I nitial I nitial Specif ication – Systems are of ten poorly structured Specif ication Version Version – Special skills (e. g. in languages f or rapid prototyping) may be required • Applicability Outline I ntermediate Outline I ntermediate Development I ntermediate – For small or medium- size interactive systems Development I ntermediate Description Versions Description Versions Versions Versions – For parts of large systems (e. g. the user interf ace) – For short- lif etime systems Final Final Validation Validation Version Version 4

Formal Systems Development Formal Systems Development • Based on the transf ormation of a Requirements Requirements mathematical specif ication through Def inition Def inition dif f erent representations to an executable program Formal Formal • Transf ormations are ‘correctness- Specif ication Specif ication preserving’ so it is straightf orward to show that the program conf orms Formal to its specif ication Formal Transf ormation Transf ormation • Embodied in the ‘Cleanroom’ approach to sof tware development I ntegration & I ntegration & System Testing System Testing Formal Transf ormations Formal Systems Development • Problems Formal Transf ormations – Need f or specialised skills and training to apply the technique T1 T4 T3 T2 – Dif f icult to f ormally specif y some Formal Executable Formal Executable R1 R2 R3 aspects of the system such as the R1 R2 R3 Specif ication Program Specif ication Program user interf ace • Applicability P1 P2 P3 P4 P1 P2 P3 P4 – Critical systems especially those where a saf ety or security case must be Proof s of Transf ormation Correctness made bef ore the system is put into operation Reuse- oriented Development Reuse- oriented Development Requirements Requirements Specif ication • Based on systematic reuse where Specif ication systems are integrated f rom existing Component Component components or COTS (Commercial- of f - Analysis Analysis the- shelf ) systems Requirements • Process stages Requirements Modif ication Modif ication – Component analysis – Requirements modif ication System Design System Design – System design with reuse With Reuse With Reuse – Development and integration Development Development • This approach has received a lot of & I ntegration & I ntegration attention recently System System Validation Validation 5