University Of Toronto Lecture 21: Program Types

2y ago
37 Views
4 Downloads
310.13 KB
5 Pages
Last View : 1m ago
Last Download : 2m ago
Upload by : Brady Himes
Transcription

University of TorontoSource: Adapted from Lehman 1980, pp1061-1063 S-type Programs (“Specifiable”) problem can be stated formally and completelyBasics of Software Evolution acceptance: Is the program correct according to its specification? This software does not evolve. Laws of software evolution A change to the specification defines a new problem, hence a new program Requirements Growth Software Aging Department of Computer ScienceProgram TypesLecture 21:Software Evolution University of TorontoDepartment of Computer Science Basics of Change ManagementP-type Programs (“Problem-solving”) imprecise statement of a real-world problem acceptance: Is the program an acceptable solution to the problem? Baselines, Change Requests and Configuration Management Software Families - The product line approach Requirements Traceability This software is likely to evolve continuously because the solution is never perfect, and can be improved because the real-world changes and hence the problem changes Importance of traceabilityE-type Programs (“Embedded”) A system that becomes part of the world that it models Traceability tools acceptance: depends entirely on opinion and judgement This software is inherently evolutionary changes in the software and the world affect each other1 Easterbrook 2004University of TorontoUniversity of TorontoDepartment of Computer Scienceformalstatementof problemrealworldmaybe ofinterest tocontrols theproductionofSource: Adapted from Lehman 1980, pp1061-1063changePROGRAMsolutionrealworldP-type change continues until it is judged more cost effective to replace the system comparechange unless steps are taken to control it.change solution with statistically determinable trends and invariants abstractview of worldConservation of Organizational Stability During the active life of a software system, the work output of adevelopment project is roughly constant (regardless of resources!) model Easterbrook 2004Fundamental Law of Program Evolution Software evolution is tionIncreasing Complexity As software evolves, its complexity increases requirementsspecificationE-typereal worldContinuing Change Any software that reflects some external reality undergoes continual changeor becomes progressively less usefulabstractview of worldprovidesS-typeDepartment of Computer ScienceLaws of Program EvolutionSource: Adapted from Lehman 1980, pp1061-1063mayrelateto2 Easterbrook 2004Conservation of Familiarity The amount of change in successive releases is roughly constant3 Easterbrook 200441

University of TorontoDepartment of Computer ScienceRequirements GrowthAlternative lifecycle modelsSource: Adapted from Davis 1988, pp1455-1459 Traditional development alwayslags behind needs growthUser needsThrowaway PrototypingUser needs Easterbrook 2004University of TorontoTimeIncremental DevelopmentUser needsTimeAutomated Software SynthesisUser needsTime5Time6 Easterbrook 2004University of TorontoDepartment of Computer ScienceSoftware “maintenance”Department of Computer ScienceSoftware AgingSource: Adapted from Blum, 1992, p492-495Source: Adapted from Parnas, 1994Maintenance philosophies “throw-it-over-the-wall” - someone else is responsible for maintenanceCauses of Software Aging Failure to update the software to meet changing needs investment in knowledge and experience is lost maintenance becomes a reverse engineering challenge Customers switch to a new product if benefits outweigh switching costs Changes to software tend to reduce its coherence “mission orientation” - development team make a long term commitment tomaintaining/enhancing the software User needs(shaded area)Shortfall first release implements onlypart of the original requirementsAdaptability functional enhancement adds newLateness(slope of line)functionalityLongevity eventually, further enhancementbecomes too costly, and areplacement is plannedTimedtsrese the replacement also onlyseence l i v esehahamaaplpeeimplements part of itseplttirre t dreenenquntrequirements,dreememrsan e m eyfincncfe and so on.iacazthhee p l aenenenfr r eid Evolutionary PrototypingInappropriatenessFunctionality Imagine a graph showing growthof needs over time May not be linear or continuous(hence no scale shown)conventionaldevelopmentFunctionality User needs evolve : Adapted from Davis 1988, pp1453-1455 Davis’sDepartment of Computer ScienceFunctionalityUniversity of Toronto Costs of Software Aging Owners of aging software find it hard to keep up with the marketplaceBasili’s maintenance process models: Deterioration in space/time performance due to deteriorating structure Quick-fix model Aging software gets more buggy changes made at the code level, as easily as possible rapidly degrades the structure of the software Each “bug fix” introduces more errors than it fixes Iterative enhancement model Changes made based on an analysis of the existing system attempts to control complexity and maintain good designWays of Increasing Longevity Design for change Document the software carefully Full-reuse model Requirements and designs should be reviewed by those responsible for itsmaintenance Starts with requirements for the new system, reusing as much as possible Needs a mature reuse culture to be successful Software Rejuvenation Easterbrook 20047 Easterbrook 200482

University of TorontoUniversity of TorontoDepartment of Computer ScienceManaging Requirements Change Change ManagementManagers need to respond to requirements change Add new requirements during developmentConfiguration Management Each distinct product is a Configuration Item (CI) But not succumbing to feature creep Each configuration item is placed under version control Modify requirements during development Control which version of each CI belongs in which build of the system Because development is a learning process Remove requirements during development requirements “scrub” for handling cost/schedule slippage Department of Computer ScienceBaselines A baseline is a stable version of a document or system Safe to share among the teamKey techniques Formal approval process for changes to be incorporated into the nextbaseline Change Management Process Release Planning Requirements Prioritization (previous lecture!) Requirements TraceabilityChange Management Process All proposed changes are submitted formally as change requests Architectural Stability (next week’s lecture) A review board reviews these periodically and decides which to accept Review board also considers interaction between change requests9 Easterbrook 2004University of TorontoUniversity of TorontoDepartment of Computer ScienceTowards Software Families Libraries of Reusable Components From IEEE-STD-830: Backward traceability program development libraries (e.g. Java AWT, C libraries) i.e. to previous stages of development. the origin of each requirement should be clearDomain Engineering Forward traceability i.e., to all documents spawned by the SRS. Facilitation of referencing of each requirement in future documentation depends upon each requirement having a unique name or reference number. Divides software development into two parts: domain analysis - identifies generic reusable components for a problem domain application development - uses the domain components for specific applications. Department of Computer ScienceRequirements Traceability domain specific libraries (e.g. Math libraries) 10 Easterbrook 2004Software Families From DOD-STD-2167A: A requirements specification is traceable if: Many companies offer a range of related software systems“(1) it contains or implements all applicable stipulations in predecessor document(2) a given term, acronym, or abbreviation means the same thing in all documents(3) a given item or concept is referred to by the same name in the documents(4) all material in the successor document has its basis in the predecessordocument, that is, no untraceable material has been introduced (5) the two documents do not contradict one another” Choose a stable architecture for the software family identify variations for different members of the family Represents a strategic business decision about what software to develop Vertical families e.g. ‘basic’, ‘deluxe’ and ‘pro’ versions of a system Horizontal families similar systems used in related domains Easterbrook 200411 Easterbrook 2004123

University of TorontoUniversity of TorontoDepartment of Computer ScienceImportance of Traceability Verification and Validation assessing adequacy of test suite assessing conformance torequirements assessing completeness, consistency,impact analysis detecting requirements conflicts checking consistency of decisionmaking across the lifecycle MaintenanceDocument access full traceability is very expensive and time-consumingProcess visibility development vs. V&V much of the benefit comes late in the lifecycleManagement testing, integration, maintenance change management risk management control of the development process No common schema exists for classifying and cataloging these In practice, traceability concentrates only on baselined requirements Tracing design rationale13Source: Adapted from Palmer, 1996, p365University of TorontoSize and diversity Huge range of different document types, tools, decisions, responsibilities, Assessing change requests Easterbrook 2004Delayed gratification the people defining traceability links are not the people who benefit from it provides an audit trail Cost very little automated support ability to see how the software wasdeveloped assessing over- and under-design investigating high level behaviorimpact on detailed specificationsTraceability Difficulties ability to find information quickly inlarge documents Easterbrook 2004Department of Computer ScienceLimitations of Current ToolsCoverage: Informational Problems Tools fail to track useful traceability information links from requirements forward to designs, code, test cases, e.g cannot answer queries such as “who is responsible for this piece ofinformation?” links back from designs, code, test cases to requirements links between requirements at different levels 14Source: Adapted from Palmer, 1996, p365-6University of TorontoDepartment of Computer ScienceCurrent Practice Department of Computer Science inadequate pre-requirements traceabilityTraceability process “where did this requirement come from?” Assign each sentence or paragraph a unique id number Manually identify linkagesLack of agreement over the quantity and type of information to trace Use manual tables to record linkages in a document Use a traceability tool (database) for project wide traceability Tool then offers ability toInformal Communication People attach great importance to personal contact and informalcommunication follow links find missing links measure overall traceability These always supplement what is recorded in a traceability database But then the traceability database only tells part of the story! Even so, finding the appropriate people is a significant problem Easterbrook 2004Source: Adapted from Palmer, 1996, p367-815 Easterbrook 2004Source: Adapted from Gotel & Finkelstein, 1993, p100164

University of TorontoDepartment of Computer ScienceProblematic Questions Involvement Responsibility & Remit Who has been involved in the production of this requirement and how? Who is responsible for this requirement? who is currently responsible for it? at what points in its life has this responsibility changed hands? Within which group’s remit are decisions about this requirement? Change At what points in the life of this requirements has working arrangements ofall involved been changed? Notification Who needs to be involved in, or informed of, any changes proposed to thisrequirement? Loss of knowledge What are the ramifications regarding the loss of project knowledge if aspecific individual or group leaves? Easterbrook 2004Source: Adapted from Gotel & Finkelstein, 1997, p100175

domain specific libraries (e.g. Math libraries) program development libraries (e.g. Java AWT, C libraries) Domain Engineering Divides software development into two parts: domain analysis - identifies generic reusable components for a problem domain application development - uses the domain

Related Documents:

Introduction of Chemical Reaction Engineering Introduction about Chemical Engineering 0:31:15 0:31:09. Lecture 14 Lecture 15 Lecture 16 Lecture 17 Lecture 18 Lecture 19 Lecture 20 Lecture 21 Lecture 22 Lecture 23 Lecture 24 Lecture 25 Lecture 26 Lecture 27 Lecture 28 Lecture

Lecture 1: A Beginner's Guide Lecture 2: Introduction to Programming Lecture 3: Introduction to C, structure of C programming Lecture 4: Elements of C Lecture 5: Variables, Statements, Expressions Lecture 6: Input-Output in C Lecture 7: Formatted Input-Output Lecture 8: Operators Lecture 9: Operators continued

Toronto Music Strategy 2 The Toronto Music Sector in Numbers Invest Toronto ranks Toronto as North America's 3rd-largest music market.Toronto is home to anada's largest community of artists;2 as such, it is also unquestionably the largest music city in Canada and the centre of the country's music industry.

Toronto Downtown 475 Yonge Street, Toronto, ON M4Y 1X7 1 416-924-0611 . Courtyard Marriott Toronto Downtown 2019 Wedding Package . Courtyard Toronto Downtown 475 Yonge Street, Toronto, ON M4Y 1X7 All prices listed are in Canadian Dollars & are subject to a 15.5% taxable service charge, a taxable 1.5% administration &

Lecture 1: Introduction and Orientation. Lecture 2: Overview of Electronic Materials . Lecture 3: Free electron Fermi gas . Lecture 4: Energy bands . Lecture 5: Carrier Concentration in Semiconductors . Lecture 6: Shallow dopants and Deep -level traps . Lecture 7: Silicon Materials . Lecture 8: Oxidation. Lecture

TOEFL Listening Lecture 35 184 TOEFL Listening Lecture 36 189 TOEFL Listening Lecture 37 194 TOEFL Listening Lecture 38 199 TOEFL Listening Lecture 39 204 TOEFL Listening Lecture 40 209 TOEFL Listening Lecture 41 214 TOEFL Listening Lecture 42 219 TOEFL Listening Lecture 43 225 COPYRIGHT 2016

Partial Di erential Equations MSO-203-B T. Muthukumar tmk@iitk.ac.in November 14, 2019 T. Muthukumar tmk@iitk.ac.in Partial Di erential EquationsMSO-203-B November 14, 2019 1/193 1 First Week Lecture One Lecture Two Lecture Three Lecture Four 2 Second Week Lecture Five Lecture Six 3 Third Week Lecture Seven Lecture Eight 4 Fourth Week Lecture .

Analysis & Research Section. (4) Crime Data: University of Toronto Map Library with permission from the Toronto Star. . Income Polarization among Toronto's Neighbourhoods, 1970-2005. 4 The Three Cities Within Toronto . For statistical reporting and research purposes, Statistics Canada defines "neighbourhood-like" local areas called .