Software Engineering I
Software Engineering I EECS 448
Popular in Course
Popular in Elect Engr & Computer Science
verified elite notetaker
This 10 page Class Notes was uploaded by Melissa Metz on Monday September 7, 2015. The Class Notes belongs to EECS 448 at Kansas taught by Staff in Fall. Since its upload, it has received 17 views. For similar materials see /class/186797/eecs-448-kansas in Elect Engr & Computer Science at Kansas.
Reviews for Software Engineering I
Report this Material
What is Karma?
Karma is the currency of StudySoup.
You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!
Date Created: 09/07/15
r N EECS 448 FALL 2004 SOFTWARE ENGINEERING I LECTURES PROFESSOR ARVIN AGAH KU EECS w u r N THE SCOPE OF SOFTWARE ENGINEERING w a Source TextBook Stephen R Schach 2004 ObjectOriented and Classical So ware Engineering Sixth Edition McGraWHill ISBN 0072865512 Introduction Software engineering is a discipline Whose aim is the production of faultfree so ware delivered on time and Within budget that satis es the user s needs Furthermore the software must be easy to modify When the user s needs change 39 Requires technical andmanagerial skills Historical Aspects A NATO study group in 1967 coined the term ro ware engineering Building so ware is similar to other engineering tasks Software engineering should use the philosophies and paradigms of established engineering disciplines to solve the so ware crisis quality of so ware generally Was unacceptably low and deadlines and budgets Were not being met r Despite many success stories a large proportion of software products still are being delivered late over budget and With residual faulw I The study by Standish Group research rm that analyzes software development projects I Study of 280000 development projects completed in 2000 only 28 of the projects Were successfully completed In a survey conducted by the Cutter Consortium in 2002 it Was reported that an astounding 78 of information technology organizations have been involved in disputes that ended in litigation I In 67 of those cases the functionality or performance of the software product did not meet up to the claims ofthe software developers I In 56 ofthose cases the promised delivery date slipped several times I In 45 of those cases the faults Were so severe that the software product Was unusable U 5 r W Analogy between software engineering and civil engineering in terms of building bridges versus operating system I Bridges collapse less frequently I Bridge collapse resulw in redesign and rebuilding I Legal matters I Bridges must be very faulttolerant I Bridges require simpler maintenance painting Economic Aspects Computer science and software engineering I Computer scientist investigates the Ways to produce software some good and some bad I Software engineer is interested in only those techniques that make sound economic sense w u AA Canceled Successful Completed late over budget andor with features missing 49 Figure 11 km the cost of introducing new technology into an organization the cost of maintenance Maintenance Aspects Maintenance is described Within the context of the software life cycle A lifecycle model is a description of the steps that should be performed When building a software product many different models have been proposed The overall lifecycle model is broken into a series of smaller steps called phases easier to perform a sequence of smaller tasks number ofphases varies from model to model The life cycle of a product is the actual series of steps performed on the software product from concept exploration through nal retirement in contrast to the lifecycle model which is a theoretical description phases ofthe life cycle may not be carried out exactly as speci ed Although there are many variations a so ware product goes through six phases 1 Requirements phase the concept is explored and refined and the client s requirements are elicited 2 Analysis specifications phase the client s requirements are analyzed and presented in the form of the specification document what the product is supposed to do sometimes called the speci cation phase a plan is drawn up the software project management plan describing the proposed development in detail 3 Design phase includes corrective maintenance software repair which consists of the removal of residual faults while leaving the specifications unchanged and enhancements software updates which consists of changes to the specifications and the implementation of those changes the two types of enhancements are perfective changes the client thinks will improve the effectiveness of the product such as additional functionality or decreased response time and adaptive changes made in response to changes in the environment such as new hardwareoperating system or new government regulations 6 Retirement the product is removed from service functionality provided no longer is of any use to the client 4 5 two consecutive processes of architectural design the product as a whole is broken down into modules and detailed design each module is designed resulting in two design documents how the product does it Implementation phase the various components undergo coding and testing unit testing the components are combined and tested as awhole integration when the developers are satisfied that the product inctions correctly it is tested by the client acceptance testing implementation phase ends when the product is accepted by the client and installed on the client s computer Postdelivery maintenance all changes to the product once the product has been delivered and installed on the client s computer Classical and Modern Views of Maintenance In the 1970s software production was viewed as consisting of two distinct activities performed sequentially development followed by maintenance Software developed classically can be described as the developmentthen maintenance model A temporal definition an activity is classified depending on when it is performed The developmentthenmaintenance model is unrealistic today The construction of a product can take a year or more during which the client s requirements may change developers have to perform maintenance before the product is installed Developers try to reuse parts of existing software products A more realistic way of looking at maintenance is that maintenance is the process that occurs when so ware undergoes modi cations to code and associated documentation due to a problem or the need for improvement or adaptation ISOIEC 12207 I Given in the standard for lifecycle processes published by the International Organization for Standardization ISO and the International Electrotechnical Commission IEC ISO is anetwork of national standard institutes of 147 countries central secretariat based in Geneva Switzerland published over 13500 internationally accepted standards I An operational de nition irrespective of when the activity takes place I De nition adopted by the Institute of Electrical and Electronics Engineers IEEE and the Electronic Industries Alliance EIA IEEEEIA 122070 Development 25 Development 3 3 Postdelivery maintenance 67 Postdelivery maintenance 75 b Figure 13 F W I Postdelivery maintenance is a subset of modern maintenance The Importance of Postdelivery Maintenance It is sometimes said that only bad software products undergo postde1ivery maintenance which is untrue I Bad software products are thrown away whereas good software products are repaired and enhanced I A software product is a model of the real world and the real world is perpetually changing as a consequence software has to be maintained constantly How much time money is devoted to postde1ivery maintenance I Some 30 years ago approximately twothirds of total software cosw I Newer data show a larger proportion 70 to 80 A w r N The average cost percentages of the classical development phases have not changed much I Approximate relative costs of the phases including maintenance I Approximate average cost percentages excluding maintenance for various projects I Breakdown of the classical maintenance costs corrective 175 perfective 605 adaptive 18 AA 9 A Sp eci ca on analysis 5 Requirements 2 Maintenance 67 Figure 12 ofprevious edition Requirements Analysis and Design Aspects The cost of correcting a fault increases steeply throughout the phases The earlier one corrects a fault the better A fault in requirements may also appear in the speci cations the design and the code Studies have shown that between 60 and 70 of all faults detected in large projects are requirements analysis or design faults It is important to improve requirements analysis and design techniques f 1 Various Prniecls 132 More Rmm between 1976 and 1981 Re uiremenb and ana1y3is 21 13 ppririraunn Imam Design phase 13 19 Implementmun phase Coding mduding unit tesingt 36 34 lnmgranon 24 29 Figure 14 k U r N 400 ects between 1974 and 1980 363 M ASMOO Kan et a 1994 r I a 350 x I u I a I quot l 300 3 I a I 250 m cu gt 4 33 E 200 200 E 8 a 4 E 150 E m 2 9 100 v a 5 50 1 3 4 n I l 1 Kequirements Anaysis Design Implementation Postdelivery specification maintenance Figure 16 k 2U r N Team Development Aspects Most software is produced by atearn of software engineers 39 Team development leads to interface problems among code components and communication problems among team members 39 Unless the team is properly organized an inordinate amount of time can be wasted in conferences between team members 39 The scope of software engineering must include techniques for ensuring that teams are properly organized and managed The scope of so ware engineering is extremely broad 39 It includes every step of the software life cycle human aspects such as team organization economic aspects and legal aspects such as copyright laws AA 2 V 3 All through the project management needs to monitor the SPMP and be on the watch for any deviation from the plan There is no separate planning phase instead planning activities are carried out all through the life cycle Why There is No Testing Phase It is reasonable to ask why there is no testing phase after the product has been implemented 39 Checking the so ware product once it is ready to be delivered is far too late 39 Although there are times when testing predominates there should never be times when no testing is being performed 39 Testing predominates toward the end of each phase veri cation and before the product is handed over to the client validation w 2a F N Why There is No Planning Phase It is impossible to develop a so ware productwithout a plan 39 Appears essential to have a planning phase at the beginning ofthe project 39 Until it is known exactly what is to be developed there is no way an accurate detailed plan can be drawn up Three types of planing activities take place when a software product is developed 1 At the beginning of the project preliminary planning takes place for managing the requirements and analysis phases 2 Once what is going to be developed is known precisely the software project management plan SPMP is drawn up which includes the budget staffing requirements and detailed schedule earliest is when the specification document is approved by the client k 1 f N 39 If testing is treated as a separate phase then there is a very real danger that testing will not be carried out constantly throughout every phase of the product development and maintenance process 39 Every software development organization should contain an independent group called the software quality assurance SQA group whose primary responsibility is to ensure that the product is what the client needs and the product has been built correctly Why There is No Documentation Phase There should never be a separate documentation phase and at all times the documentation of a software product must be complete correct and up to date 39 Large turnover in personnel in the software industry r 1 Impossible to perform the steps of a specific phase unless the documentation ofthe previous phase is complete correct andup to date Impossible to test Whether a so ware product is Working correctly unless documents are available that state how the product is supposed to behave Impossible to perform maintenance unless there is a complete and correct set of documentation that describes precisely What the product does The Object Oriented Paradigm Prior to 1975 no speci c techniques 1975 to 1985 structured or classical paradigm 39 Unable to cope With the increasing size of software products adequate for smallscale products 5000 lines of code adequate for mediumscale 50000 lines of code could not scale up to largescale 500000 lines of code such as a speci cation document a code module or amanual Strengths of the objectoriented paradigm 1 Makes maintenance quicker and easier and the chance of introducing a regression fault is greatly reduced a fault inadvertently introduced as a consequence of a change N Makes development easier the close correspondence between the objects and their counterparts in the realWorld w Welldesigned objects are independent units the conceptual independence is termed encapsulation information hiding ensures the implementation details are hidden 4 The product consists of a number of smaller largely independent units reduces the complexity of a software product productsWith 5 million lines of code are not unusual 39 Did not live up to the expectations during postdelivery maintenance twothirds of the budget for postdelivery maintenance classical paradigm did not change that 39 Either operation action oriented or attribute data oriented but not both basic components of a software product operations of the product andthe attributes on Which those operations operate Obj ectOriented Paradigm 39 Considers both attributes and operations to be equally important 39 An object is a unified software artifact that incorporates both the attributes and the operations performed on the attributes 39 An artifact is a component ofa so ware product a product in the classical paradigm is implemented as a set of modules but it is essentially a single unit less successful With larger products 5 Promotes reuse because objects are independent entities they can be utilized in future products The j t 39 quot 39 Phase for classical paradigm versus Workflow for objectoriented ha a mndified quotf F terms are distinct 39 One of the steps of objectoriented analysis Work ow is to determine classes because class is a kind of module architectural design is performed during the objectoriented analysis Work ow A In classical paradigm a sharp transition between the analysis phase and the design phase from What to do to how to do it In objectoriented analysis objects enter the life cycle from the very beginning objects are extracted in the analysis Work ow deigned in the design Work ow coded in the implementation Work ow an integrated approach With smooth transitions Classical Paradigm 2a AnalySls Spectllmtlan phase 1 Design phase Archrtcctural design extract thc modules Detailed design 4 lmplementntlan phase 4 programman language Integrate ObjectrOriented Paradigm medonented analysn wnrktlow Extract the classes tai ed deny a Obtectmlenten design workrlow Dc I n Obieetnrienten implementation workllew amenoriented pregrammlng language Integrate Figure 19 kAA F W Classizal Paradigm ObjectOriented Paradigm L Requiremens hase l Requiremenrsworkllow 2 Analysis ltpncilltallnn phaie 2 on artoriented anal sis workllnw 3 Design phase 339 Objectoriented design worki ow 4 implementation phase 439 Objeclroriented implementation workllow s Postdelivery maintenance 5 Postdelivery maintenance 6 Retiremert 6 Relirement Figure 18 k 3U r N The Object Oriented Paradigm in Perspective The issues With obj ectoriented paradigm I The obj ectoriented paradigm has to be used correctly just as easy to misuse as any other paradigm When correctly applied obj ectoriented paradigm can solve some but not all of the problems of classical paradigm I The obj ectoriented paradigm has some problems of its own discussed later I The obj ectoriented paradigm is the best approach available today and it can be superseded by a superior technology in the future Terminology A number of software engineering terms are de ned I Client the individual Who Wants a product to be build developed 22 Developers members ofthe team responsible for building the product Internal software development both the client and developers are art of the same organization Contract software the client and the developers are independent organizations User the person or persons on whose behalf the client has commissioned the product and who will utilize the so ware Custom software written for one client Commercial offtheshelf COTS software multiple copies of software are sold at much lower prices to a large number of buyers recovering the cost of developing a product by volume selling Shrinkwrapped sof tware earlier term for COTS software because ofthe box containing the material nowadays of ten downloaded over the World Wide Web System design the third phase design phase Product a nontrivial piece of software the end result of a process is a product System the combinedhardware and software Mistake fault failure error defined in IEEE standard 61012 a programmer make a mistake the consequence of that mistake is a fault in the code executing the so ware product results in a failure observed incorrect behavior an error is the amount by which aresult is incorrect 39 Defect generic term that refers to a fault failure or error minimize the use 39 Bug term for a fault minimize the use V N 39 Clickware sometimes used for COTS software 39 Opensource software developed and maintained by a team of volunteers and maybe downloaded and used free of charge becoming very popular eg Linux operating system and Apache Web server the source code is available to all with most commercial products only the executable version is sold can be of high quality any user can scrutinize the source code 39 Sof tware consists of notjust the code but all the documentation that is an intrinsic component of every project eg specification document legal documents manuals 39 System analysis the first two phases of traditional software development requirements and analysis phases k 3U f N Ethical Issues Most societies for professionals have a code of ethics to which all its members must adhere 39 They express similar sentiments 39 Vital for the future ofthe professions to rigorously adhere to such codes The Software Engineering Code of Ethics and Professional Practice 39 Jointly approved by the IEEECSACM Joint Task Force on Software Engineering Ethics and Professional Practices 39 Two major societies for computer professionals the Computer Society of IEEE IEEECS the Association for Computing Machinery ACM 39 39Ihe stande for teaching and practicing software engineering 39 It is lengthy and a short version is also produced w 29 r N Version 52 Software engineers shall commit themselves to making the analysis specification design development testing and maintenance of software a beneficial and respected profession In accordance with their commitment to the health safety and welfare of the public software engineers shall adhere to the following Eight Principles 1 Public Software engineers shall act consistently with the public interest 2 Client andEmployer Software engineers shall act in amanner that is in the best interests of their client and employer consistent with the public interest 3 Product Software engineers shall ensure that their products and related 39 39 Inr hi he tnrnfe innal I 39 4 Judgment 39 maintain inte ritv quot in their professional judgment k 37 v Fquot 4 9 Management Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance Profession Software engineers shall advance the integrity and reputation ofthe profession consistent with the public interest Colleagues Software engineers shall be fair to and supportive of their colleagues Self So ware engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession
Are you sure you want to buy this material for
You're already Subscribed!
Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'