Popular in Course
Popular in Computer Engineering
This 18 page Study Guide was uploaded by Liliane Borer on Monday October 26, 2015. The Study Guide belongs to COE1530 at University of Pittsburgh taught by Staff in Fall. Since its upload, it has received 53 views. For similar materials see /class/229354/coe1530-university-of-pittsburgh in Computer Engineering at University of Pittsburgh.
Reviews for SOFTWAREENGINEERING
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: 10/26/15
Software Engineering CS COE 1530 Final Review a ism Software Engineering Fall 2nd Dates I Final exam I Monday 1213 800 950 in this room I cumulative I Summary of Apache Mozilla case study I due Wednesday 121 in class I Test cases beta test results I due Friday 123 noon I Acceptance Testing Code deadline I Monday 126 11am I bring you own laptop one per group describe design demonstrate functionaiity Quality terminology i What are bugs I Error human mistake I Fault result of mistake evidenced in some development or maintenance product I Failure departure from the system s required behavior Garvin s perspectives on giquality I Transcendental View something we recognize ut can t define I User View fitness for purpose I Manufacturing View conformance to specification I Product View tied to inherent product characteristics I Valuebased View depends on customer39s willingness to pay I McCall s Quality Model External quality criteria I Reliability I Efficiency I Integrity I Usability I Maintainability I Testabquotty Portability I Reusability I Intero pe ra bi ity 5 law Sahwave Engineering Pal 2mm 1 Systems approach to SE I Identify activities and objects I Define the system boundary I Consider nested systems system interrelationships Key factors altering software g ngineering practice asserman I criticality of timeto market for commercial producB I shifB in economics of computing lower HW higher developmentmaintenance costs I availability of powerful desktop computing I extensive local and widearea networking I availability and adoption of 00 technology I graphical user interfaces I unpredictability of waterfall model of development Wasserman s basis for good g software engineering I Abstraction I Analysis and design methods and notations I User interface prototyping I Software architecture I Software process I Reuse I Measurement I Tools and integrated environments 1 Capturing the requirements I Requirement a feature of the system or a description of something the system is capable of doing in order to fulfill the system39s purpose I Three kinds of requirements I those that absolutely must be met I those that are highly desirable but not necessary I those that are possible but could be eliminated 5 law Sahwave Engineering Pal 2mm Requirements documents I Requirements definition complete listing of what the customer expects the system to do I Requirements specification restates the definition in technical terms so that the designer can start on the design I Configuration management suppers direct correspondence between the two documenB s ism sanweie Engineering rdi 2mm Si Con guration management I Set of procedures that track I requirements that define what the system should do I design modules that are generated from requirements I program code that implements the dsign I tests that verify the functionality of the s stem I documents that describe the system 5 ism sanweie Engineering Fdl 2mm Functional vs nonfunctional gyequirements I Functional describes I Exam E I I Syste shal 39 Xampf A com nicateWitn external system x ribes a restriction or constraint that limils I Nonfunctional39 desc our choices for constructing a solution more than 4 hous after i i itiai data are read What conditions must be meSSage 0 be System iimits access to senior managers 5 ism Wequot Engineering Fdl 2mm Types of requirements I I Physical environment I Interfaces I Users and human factors I Functionality Documentation I Data I Resources I Security I Quality assurance 5 ism Sahwave Engineering Fai mm Characteristics of shEequirem ents I Are they correct I Are they consistent I Are they complete I Are they realistic I Does each describe something the customer needs I Are they verifiable I Are they traceable s ism Sahwave Engineering sai mm Requirements Notations I Dynamic vs Static I Examples 5 ism Sahwave Engineering Fai mm IMilestones and activities I Activity takes place over a period of time I Milestone completion of an activity a particular point in time I Precursor event or set of events that must occur in order for an activity to start I Duration length of time needed to complete an ac 39vi I Due date date by which an activity must be completed 5 Slack or float time Slack time available time real time latest staIt time earliest staIt time Critical Path I a path from start to finish in the activity graph for which the slack at every node is 0 I typically multiple critical paths not just one I Any delay of a node on a critical path delays the whole project I in contrast nodes with slack can tolerate delays I Analyzing your project in this way is called the Critical Path Method CPM 5 law Sahwave Engineering Fdl 2mm lEffort estimation I Expert judgment Y I proportion I Delphi technique I Wolverton model I Algorithmic methods E a bSY mX I S size X cost vector m multiplier abc constanls I Walston and Felix model E 5255 I Bailey and Basili model E 55 0735115 COCOMO model stages of evelopment I application composition prototyping to resolve highrisk user interface issues I size estimates in object poinls I early design I to explore alternative architectures and concepls I size estimates in function points I postarchitecture I development has begun I size estimates in lines of code Risk management reguirements I Risk impact the loss associated with the event I Risk probability the likelihood that the event will occur I Risk control the degree to which we can change the outcome Risk exposure risk probability X risk impact Three strategies for risk reduction I avoiding the risk change requirements for performance or functionality I transferring the risk transfer to other system or buy insurance I assuming the risk accept and control it risk leverage difference in risk exposure divided by cost of reducing the risk Boehm s top ten risk items I I Personnel shortfalls I Unrealistic schedules and budgels I Developing the wrong functions I Developing the wrong user interfaces I Goldplating I Continuing stream of requirements changes I Shortfalls in externallyperformed tasks I Shortfalls in externallyfurnished componenls I Realtime performance shortfalls I Straining computer science capabilities Project plan contents I oject sco I project schedule I documentation plan I project tea I data management plan resource management Ian I test plan I training plan I security p n I risk management plan I maintenance plan I technical description of system I project standards and procedures I quality assurance plan I configuration management plan Conceptual design I I Tells the customer What the svstem will do What Will happen to the d Mew I atWill e sysm loo ii rs7 I What dnoices will be offered to users7 Wh l g of e I What will the reporB and screws look like7 Characteristics of good conceptual design ll i customs language Mm no tednnical Jagon I describes system ncuons independent of irrplernmtauon linked to requiremenE Technical design I Tells the programmers what the system will do I Includes I major hardware componenls and their function I hierarchy and function of software componenls I data structures I data low 1 Five ways to create designs I Modular decomposition I Dataoriented decomposition I Eventoriented decomposition I Outsidein design I Objectoriented design 5 Three design levels I Architecture associates system components with capabilities I Code design specifies algorithms and data structures for each component I Executable design lowest level of design including memory allocation data formats bit patterns Design styles I I Pipes and filters I Objectoriented design I Implicit invocation I Layering I Repositories I Interpreters I Process control I Clientserver 1 Characteristics of good design I Component independence I coupling degree ot dependence among components I cohesion degree of relatedness of internal pare ot a component I Exception identification and handling I Fault prevention and tolerance I active I passive l Coupling highly coupled system lot of dependence between components via invocation via data transfer via control eg control codes flags 5 law Sahwave Engineering Fdl 2mm g Content Coupling one component modifies another I eg one component modifies internal data of another I very undesirable can be turned into common coupling use common data store coupling still there but at least centralized 5 law Sahwave Engineering Fdl 2mm Control Coupling some parameter passed controls execution of a component I can restrict coupling of each component executes only one function localizes control to welldefined interface 5 law Sahwave Engineering Fdl 2mm 1 Stamp amp Data Coupling I Data structure is passed from component to component to stamp coupling I Only individual data are passed data coupling 5 law Sahwave Engineering Pal 2mm g Types of Cphesion I Coincidental I parts are really unrelated and just got put together utils I should be avoided I Logical I logically related pars together eg all file io I no functional relation so still undesirable 5 law Sahwave Engineering Fdl 2mm l Types of Cohesion 2 I Temporal I functions only related by time sequence eg initialization I like logical cohesion type difficult to change I Procedural I functions grouped because they have to be pe ormed in certain order I Communicational I data fetched at same time eg from same file disk 5 law Sahwave Engineering Pal 2mm I Types of Cohe5lon 3 I Sequential I output of one component used as input in another I better than others but still unconstrained in many wa s I Functional I every part is essential to a specific function and all essential elemenls are contained in one componen t I performs the function it is designed and no others 5 151m sanweie Engineering Fdl 2mm Patterns amp Fram eworks I Patterns supportireuse of software architecture and design r r A a collaboratlons of successful solutlons to problems that arise wnen bulldan applications in a particular domain I Frameworks support reuse of detailed design and code a framework is an integrated set of components tnat collaborate to p ide a reusable arcnitecture for a famllv of I Both improve development time and reuse 5 151m sanweie Engineering Fdl 2mm Design Patterns I Represent solutions to problems that arise when developing software in a particula contex ie p ttern proplem solution pair in context capture static amp dynamic structure and collaboration a icipanls in software des39 Ign partlcular useful in artlculating how and Why to resolve nonr functlonal for Facilitate reuse of successful software architectures and design 5 151m sanweie Engineering Fdl 2mm Design Pattern Descriptions 39 Name and merit I Known uses and related roblem and context patterns 39 Forcelsj addresged I Pattern descriptions stract description of are onequot 25322 colic1336mm independent of I consequences Of use 7 09quotquot1391113919 Implementation guidelines a guage 0quot and sample code IMPI MEH fa Hon details I contrast with frameworks 5 law Sahwave Engineering Fai 2mm 39 Frameworks I are semicomplete applications I complete applications are developed by inheriting from and instantiating parameterized frameworks I provide domainspecific functionalit I eg business or telecommunication applications window systems etc I exhibit inversion of control at run time I framework determines which objecls and methods to invoke in response to evenls 5 law Sahwave Engineering rai 2mm Class Libraries Frameworks 39 amp Patterns I Class libraries I selfcontained plugabble ADTs I Frameworks I reusable semicomplete applications I Patterns I problem solution cont ltt 5 law Sahwave Engineering Fai 2mm I Design Pattern Space I Creational Patterns I initializing and configuring classes and objects I Structural patterns I decoupling interface and implementation of cl e and 0 ed I Behavioral patterns I dynamic interaction among groups of classes and objects 5 ism sanweie Engineering Pal 2pm I Creationali Patterns I Factory method I method in a derived class creates associates I Abstract factory factory for poiioing related objecE I Builder I factory for bUilding complex ObJeCE incrementally rothPe factory for cloning new instances from prototype I Singleton factory for a singleton sole instance 5 ism sanweie Engineering rai 2pm Structural Patterns apter Hand ator adapts a serye interface for a client Bridge doshacnon for binding one I Flyweight of rriany irrplerrmtauons a e sirnpiiries the interface for a subsystem rnany finesgrained I Composi e objecm snared efficiently structure for building remrsveaggregauons I Proxy Decorator eobJect approximates atmds an ObJSCt another intermediary oansparenti y s ism sanweie Engineering Pal 2pm BehaVIoral Patterns 1 I Chain of responsibility request de egated to designated service provider I Command I request as first class object I Interpreter I language interpreter for small grammar I Iterator I aggregate elemenls are accesses sequentially 5 151m sanwere Engineering Fai 2mm Behav39oraLPatterns 2 I Mediator I mediator coordinates actions between iE associates I Memento snapshot captures and restores obJect states privately I Observer dependenm update automatically when subJect changes I tate I object Whose behavior depends on im state 5 151m sanwere Engineering rai 2mm 39 Behav oral Patterns 3 I Strategy I abstraction for selecting one of many algorithms I Template met od algorin With some step supplied by a derived class I Visitor operations adapted to elemenE of a heterogeneous obJect structure 5 151m sanwere Engineering Fai 2mm Writing highquality code I Good code must be based on good design I choose right data amp control structures I choose appropriate programming languages I program into a language not in it use your own comentions standards amp class libraries if language does not provide What you need most programming principles are independent of the Specific language but depend on now you use it s ism sanweie Engineennq Fdi mm 39 Good Construction Practices I Start with a good design I decide how much little to do at keyboard I set coding conventions for names comments ayout I define how to handle errors security class interface standards reuse standards performance I program into not in s ism sanweie Engineennq Fdi mm 39 00 Designing Classes I Foundations ADTs I Interfaces I Implementation issues I When to create a class I Language dependency I Packages 5 ism sanweie Engineennq Fdi mm Think ADTs rst program 1 into enefils mde rmp ementatron deta s charges Wm be ocahzed rnterface can be more rnformatwe eg not currentFont srze 16 but use an ADT srze m were or pom eager to rmprove performance correctness r5 more otmous more eerrdocumennng ess couphng no need to D555 data everwhere dear with hrgwever rear wor d entrtres not ow rmp ementatron deta 5 15m Sa wave Enqmeennq Far 2mm
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'