Unformatted text preview:

CSC 408F/CSC2105F Lecture NotesThese lecture notes are provided for the personal use ofstudents taking CSC 408H/CSC 2105H in the Fall term2004/2005 at the University of Toronto.Copying for purposes other than this use and all forms ofdistribution are expressly prohibited.cDavid B. Wortman, 1999,2000,2001,2002,2003,2004cKersti Wain-Bantin, 2001cYijun Yu, 20040What is Software EngineeringThe science and art of building LARGE Software SystemsOn timeOn budgetWith Acceptable PerformanceWith Correct OperationLARGE means:Many people, team not individual effortMany $s spent on design and implementationOver 75,000 lines of source codeLifetime measured in yearsContinuing modification and maintenanceSoftware costs dominate hardware costs1Survey resultsQ2. Do you remember the LOC of the software?A1000 : 7 (15%)B10000 25 (54%)C100000 3 (6%)D 100000 6 (14%)E Don’t know LOC 5 (11%)Q3. How many people were involved in the dev. team?A 1: 12 (26%)B 2-5 27 (37%)C other 7 (15%)C no answer 10 (22%)2Q4. How long did it take to complete?A 1 day: 0 (0%)B 1 month 12 (17%)C 1 year 11 (24%)C other 23 (50%)D no answer 4 (9%)Q6. Which programming language was used?A C/C++ : 20 (43%)B Java 18 (41%)C other 10 (21%)3What Makes Large Software Different ?Scale Precludes total comprehensionComplexity Number of functions, modules, pathsTeam Effort Continuingly changing body of programmersCommunication Distribution of specifications and documentationContinuing Change During design & implementationDuring lifetimeLifetime Measured in years or decadesImprecise goals Conflicting or ambiguous, changing4Issues in Software EngineeringMajor concern is the construction of large programs.Central theme is mastering complexity.Software evolves over its lifetime.The efficiency of software development is of crucial importanceRegular cooperation between people is an essential and unavoidable part oflarge software development.Software has to support its users effectively.Software Engineering is a field in which members of one culture (designers,programmers) create artifacts on behalf of members of another culture (endusers).5The Ideal Goals of Software EngineeringProduct Quality. To produce software that is correct and has high quality interms of user satisfaction.Productivity– To produce software with a minimum of effort.– To produce software at the lowest possible cost.– To produce software in the least possible time.Profitability. To maximize the profitability of the software production effort.Maintenability. To produce software that can be maintained with a minimumof effort.In practice, none of these ideal goals is ever completely achievable. Thechallenge of Software Engineering is to see how close we can get to achievingthese goals. The art of software engineering is achieving the best balance amongthese goals for a particular project.6Goodness (Quality) Goals ConflictAll goodness attributes cost $s to achieveInteraction between attributesHigh efficiency may degrade maintainability, reliabilityMore complex User Interface may degrade efficiency, maintainability,and reliabilityBetter documentation may divert effort from efficiency and reliabilitySoftware Engineering management has to trade-off satisfying goodness goalsSoftware Development is (usually) done with a relatively inelastic upperbound on resources expended.There Ain’t No Such Thing As A Free Lunch7Need Different Approaches for Developing Large SoftwareNeed formal management of software production processFormal & detailed statement of requirements, specification and designMuch more attention to modularity and interfacesMust be separable into manageable piecesNeed configuration management and version controlMore emphasis of rigorous and thorough testingNeed to plan for long term maintenance and modificationNeed much more documentation, internal and external”A typical commercial software project involves creating more than 20 kinds of paper documents on suchitems as requirements and functional, logic, and data specifications. For civilian projects, at least 100English words are produced for every source code statement in the software. For military software,about 400 words are produced for every source code statement. Many new software professionals aresurprised when they spend more time producing words than code.”aaCapers Jones, Gaps in programming education,IEEE Computer, April 1995 v.28 n.4, pg. 718Laws of Software Evolutiona1. Law of Continuing Change A system that is being used undergoescontinuous change until it is judged more cost effective to restructure thesystem of replace it by a completely new system.2. Law of Increasing Complexity A program that is changed becomes less andless structured (entropy increases ) and thus becomes more complex.One has to invest extra effort in order to avoid increasing complexity.3. Law of Program Evolution The growth rate of global system attributes mayseem locally stochastic, but is in fact self-regulating with statisticallydeterminable trends.4. Law of Invariant Work Rate The global progress in software developmentprojects is statistically invariant.aM.M. Lehman and L.A. Belady Program Evolution, - Processes of Software Change, AcademicPress, 198595. Law of Incremental Growth Limit A system develops a characteristic growthincrement. When this increment is exceeded, problems concerning qualityand usage will result.AttributeSystemTime10Header restructuring project11Significance of Lehman & Belady’s WorkUnless proactive steps are taken– the maintainablilty of a software system will decrease over time– the complexity of a system will increase over time– disorder in the system will increase over timeChange is inevitable, we must learn to accommodate it.The amount of maintenance that can be done in a given period of time cannotbe (on average) significantly increased by the addition of more resources.Attempting to make too large a change in a system will lead to lower qualitysoftware12Large Software DevelopmentThe requirements, specification and design of a software system are written by a teamof developers.A hierarchical approach is often used, with sub-systems being developed by differentteams.Individual modules (source files) are written, debugged, tested and documented bysmall teams of programmers.The modules in a system exist in some arbitrary client-server configuration. Someform of


View Full Document

Toronto CSC 408F - Lecture Notes

Download Lecture Notes
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture Notes and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture Notes 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?