Why do we need this course?

  • Published on

  • View

  • Download

Embed Size (px)


Why do we need this course?. Why engineer software? Cant we just hack at it, until we get something that works? Many people/companies do this anyway Answer: cant hack it if we care about quality If a system is not put together in a well-organized manner, the chance for bugs is greater - PowerPoint PPT Presentation


<ul><li><p>Why do we need this course?Why engineer software?Cant we just hack at it, until we get something that works?Many people/companies do this anywayAnswer: cant hack it if we care about qualityIf a system is not put together in a well-organized manner, the chance for bugs is greaterAnother answer: You cant just hack together a 106 LOC systemComplex systems are impossible to build in an ad-hoc manner</p></li><li><p>Introduction: software qualitySoftware is often buggyIn critical applications, bugs can lead to drastic consequencesTherac-25 malfunctions killed or severely injured several people in 1985-87Ariane 5 launcher crash on 4/6/1996Airbus problemsBanking software failuresMany more The main reason for bugs is enormous complexity of softwareNeed techniques to cope with this complexity</p></li><li><p>Quality IssuesSoftware is now an integral part of every facet of our societal infrastructureAir traffic controlTelecommunicationFinancial infrastructurePoor quality software menaces the maintenance of that infrastructure Software is the "Grand Enabler" holding the key to scientific and engineering challengesHuman genome projectSpace explorationWeather prediction</p></li><li><p>Why isnt software quality up to snuff?deliver prototypes"leave it to the marketplace"unsophisticated consumersdon't know what they wanttolerate high failure rates "the computer is down"misled by "coverups" in banking, finance, communicationslack of understanding of risksYear 2000 (Y2K)</p></li><li><p>Software is everywherefrom Phillips:TV can have 600Kbytes of codeVCR has 265KbytesCell phone has 512KbytesCar radio has 64-256Kbytes</p></li><li><p>What is software?CodeVarious design documentsUser manualsDevelopment plans, timelines, and budgetsMaintenance documentsThe way of producing software (process)</p></li><li><p>Desirable qualities of software systemsReliabilityPerforms the required functions correctlyThe rate of failures is lowMaintainabilityUnderstandabilityChangeabilitySimplicityReusabilityThe solution to a problem should be as general as possibleUser friendlinessEfficiency</p></li><li><p>Some interesting numbersAbout 25% of s/w projects failFailure rate increases as the size of the project increasesCosts about $100/LOCRanges between $10-$600Typical programmer produces about 30 LOCs a dayRanges between 10-100 LOCs25 faults/KLOCRanges between 3-100 faults/KLOC</p></li><li><p>Software costsDevelopment costsgenerally measured in hundreds to thousands of dollars per delivered LOCmany artifacts associated with a line of codetesting and analysis is usually 50% of this costMaintenance costs2-3 times as much as development </p></li><li><p>Software Costscodereqts and designtesting15%35%50%Development costsFull lifecycle costsmaintenancetestingcodereqts/design</p></li><li><p>ModelsSoftware code is too complex to reason about it directlyNeed a higher level representation, called designCaptures only the most important relevant characteristics of the problemNeeds to capture the behavior of the problem accuratelySoftware code must conform to its design</p></li><li><p>Software EngineeringName coined at the NATO Science Committee Conference, October 1968Engineering-- established, scientifically sound practices that well trained practitioners follow Software Engineering-- the application of scientific knowledge to the the development and maintenance of software systems Software-- ALL associated artifacts to assist with the development, operation, validation, and maintenance of programs/software systemse.g., code, documentation, designs, requirements, user manuals, installation manuals, test cases, test results, bug reports, revision history, make files,...</p></li><li><p>The nature of softwareSoftware is a complex, intricately interconnected data aggregateSoftware Development is the process of creating such a complex product, while continuously assuring that it remains consistentSoftware Engineering combines some of the approaches of classical engineering with some of the abstract approaches of mathematics</p></li><li><p>A software product is a complex web of intertwined software objects, connected by a multitude of diverse relations and constraintssome types of objects:source codedesignstestcasesdocumentationsome types of relationships:is invoked byis derived fromis consistent withis a version of</p></li><li><p>Trends in Software Expansion (Bernstein, 1997)</p></li><li><p>What is novel about software, compared to other fields of engineering?product is unprecedentedly complexapplication horizons expand too fast--with human demands/imaginationconstruction is human-intensive solutions require unusual rigor extremely malleable--can modify the product all too easily</p></li><li><p>How to increase Software QualityTreat software as a PRODUCT produced in a systematic way by a PROCESS designed and implemented to achieve explicit quality objectivesBuild quality in Define software product formallyDefine software process formallyReason about the product and process formallyIncorporate validation as integral steps in the process</p></li><li><p>Software Lifecyclerequirementsdesign specscodingtestingmaintenancereqts. analysisvalidationvalidationrevalidationadequacy</p></li><li><p>Waterfall Modelrequirements-- a complete,consistent specification of what is neededprovides visibility for customers, developers, and managersbenchmark for testing and acceptancereduces misunderstandingsrequirements analysisevaluate completeness and consistencyevaluate needs and constraintsevaluate feasibility and costsdevelopment and maintenance costsProbability of success</p></li><li><p>Waterfall Model (continued)design specifications--a description of how the requirements are to be realizedhigh-level architectural designlow-level detailed designdesign validationtraceability between requirements and design decisionsinternal consistency</p></li><li><p>Waterfall Model (continued)code--realization of the design in executable instructionscode validation assure coding and documentation standards have been maintainedinternal consistencye.g., syntactic analysis, semantic analysis, type checking, interface consistencyconsistency between design/requirements and code</p></li><li><p>Waterfall Model (continued)testing--reveal problems, demonstrate behavior, assess reliability, evaluate non-functional requirements (e.g., performance, ease of use)unit testingintegration testingsystem testingacceptance testingregression testingtesting validationadequacy of the testcases </p></li><li><p>Waterfall Model (continued)maintenance--the process of modifying existing software while leaving its primary functionality intactcorrective maintenance-- fix problems (20%)adaptive maintenance-- add new functionality/enhance existing features (30%) perfective maintenance-- improve product (50%)e.g., performance, maintainability3 primary stepsunderstand existing software change existing softwarerevalidate existing softwaremaintenance involves all the previous phases of the lifecycle</p></li><li><p>Is the waterfall model an appropriate process model?recognizes distinct activitiesclearly oversimplifies the processwait, wait, wait, surprise modelactual processes are more complexnumerous iterations among phasesnot purely top downdecomposition into subsystemsmany variations of the waterfall modelprototypingre-engineeringrisk reduction...</p></li><li><p>Barriers to engineering softwareIndustrys short term focusShortage of skilled personnelInadequate investment in R&amp;DPoor technology transfer modelsInsufficient standards</p></li><li><p>Industrys short term focus"bottom line orientation"emphasis on time to marketnot life cyclereturn on investmentstartups cannot invest in R&amp;D until product established in marketplacewithout the R&amp;D, takes too long for next or improved productmarket strategy driven by investors who want impressive short term gains</p></li><li><p>Industrys short term focussoftware housesintensely competitiveoften don't use own technologykeep development cost down, fix laterunsophisticated industrieslack of technical expertiselack of administrative experienceoverselling the technology</p></li><li><p>Barriers to engineering softwareindustrys short term focus shortage of skilled personnelinadequate investment in R&amp;DPITAC (Kennedy-Joy) ReportUS SW GNP is $228B but less than 1% spent on R&amp;DPoor technology transfer models tend to "toss over the fence"Lack of standards</p></li><li><p>What do we need?Scientific basisOrganized disciplineR&amp;D strategyTrained professionalsTechnology transfer strategiesQuality control</p></li><li><p>Certification and Licensing?Currently, software engineering is not one of the 36 engineering professions recognized and licensed in the United States. 48 states prohibit using the term "engineer" without a license Texas has forced universities to stop MSSETennessee prohibits the use of "software engineering" in business literature and advertisingNew Jersey considered, but did not pass, a regulation that would have required licensing of all SW professionalsIEEE/CS &amp; ACM established Commission on Software Engineering in 1993</p></li><li><p>High-level Goals of Software Engineeringimprove productivityreduce resources e.g., time, cost, personnelimprove predictabilityimprove maintainabilityimprove quality</p></li><li><p>Topics for the courseBrief UML intro and object-oriented basicsRequirements elicitationIdentifying the ways in which the system is going to be usedWorking on usage scenariosTalking to the customersOO analysisFiguring out the basic functionality of the systemIdentifying initial classesFiguring out the control flow in the systemSeparating the classes by their general functionalityInitial relationships among classes, including inheritance</p></li><li><p>Topics for the course (cont.)High-level designIdentification of subsystemsLayersDeployment diagramsAccess controlElaboration of control flowBoundary conditionsObject-level designElaboration of classesWhich ones are to keep and which ones are to throw awayVisibility of fields and methodsElaboration of class interactionsSequence diagramsImproving inheritance and associations</p></li><li><p>Topics for the course (cont.)Configuration managementControlling change in softwareTestingTechniques for detecting errors in softwareSoftware process modelsHigh-level views of the complete lifecycle of software developmentSoftware metricsDistributed systemsThe restProject managementPlanningEtc.</p></li><li><p>Reading materialTextbookSoftware Engineering 8th edition, Ian Sommerville, Addison-WesleyI will suggest some extra material</p></li><li><p>Basic OO terms: object and classObjectrepresents anything that can be distinctly identifiedhas a unique identitywhat does it represent?Has a unique statewhat is it doing?Has a set of possible behaviorswhat are all possible things it can be doing?Classrepresents a set of objects with similar characteristics and behaviorin other words, the type of an object</p></li><li><p>Class notationUMLClass Name</p><p>field 1field n</p><p>method 1method n</p></li><li><p>Example: class TreeUMLJavaClass Tree { private float height_; private int noOfBranches_; private Classification species_;</p><p> public void die() { } public void germinate() { } public void grow(Date untilDate) { } public void shedLeaves() { }}</p></li><li><p>Interaction among objectsAn OO program is a collection of communicating objectsThis communication happens via message passingTo send a message to object b, object a has to call a method of bb.();</p></li><li><p>ModulesA module is a part of an applicationA module captures some well-defined functionalityModules can be defined hierarchicallyA module can contain a number of lower-level modulesA module consists of entitiesFunctionsAlgorithmsObjectsLower-level modulesA module can be a class</p></li><li><p>Important OO principles: cohesion and couplingCohesion refers to how well the entities of a class fit togetherHigh cohesion, goodentities are highly relatedLow cohesion, badentities are not highly relatedCoupling refers to the amount of dependency among the modulesHigh coupling, badthe amount of information that one module should reveal to another is excessiveLow coupling, good</p></li><li><p>Important OO principles: abstraction and encapsulationAbstraction in terms of a module represents the amount of information that the users of this module need to be able to use itThe smaller this amount of information, the betterEncapsulation is the principle of not making internal information visible to the usersAlso known as information hidingEncapsulation improves abstractionInternal changes can be made without affecting the way that users use this module</p></li><li><p>Important OO principles: interfaceInterface to a module is the amount of information that this module makes visibleAbstraction can be characterized as complexity of the interfaceInterface represents a contract between the module and its usersthe module: Here are all the services that I can provide to youUML notation</p></li><li><p>Important OO principles: inheritanceThe idea is to define a relationship where class A is more general than class BB inherits from AB is a subclass of AA is a superclass of BB is a kind of AExample:</p></li><li><p>Inheritance (cont.)Multiple levels of inheritance are possibleSubclasses inherit attributes and methods of their superclasses</p></li><li><p>Important OO principles: polymorphismA related but different kinds of functionality can be implemented by several different modulesIf the interfaces to all these modules are the same, they can be used in exactly the same wayIn the program, a module being used can be changed dynamically, as long as the interface remains the same</p></li><li><p>Important OO concepts: aggregationAggregation is a relationship where one class is a part of another</p></li><li><p>Important OO concepts: associationAssociation is a general relationship among two classes</p></li><li><p>Class diagram for a game of dice</p></li><li><p>Modeling dynamic behaviors: state and sequence diagramsStatic behavior represents relationships among classesClass diagramsinheritanceaggregationassociationDynamic behavior represents interactions among objectsState diagramsSequence diagrams</p></li><li><p>State diagramsRepresent all possible behaviors of an objectConsist of states and transitionsAt any moment of time, an object is in some stateDoing somethingHaving certain qualitiesA transition represents the object moving from one state to anotherTransitions are triggered by eventsMay have guards and side-effectsHas a start stateMay have a final stateStates can be composite, called hyperstates</p></li><li><p>State diagram example: Game class</p></li><li><p>Sequence diagramsIllustrate interaction of several objects</p></li><li><p>AnnotationsAnnotations, or comments, may be added to any part of any UML diagramNotation:This class serves as avery general type ofa car. You have toinstantiate one of itschildrenCar</p></li></ul>