CSE350 Software Design and Engineering University of Pennsylvania Office: 254 Moore GRW, Phone: April 16 th, 2002

Administrative lDemos in 100D lGroup 1, 12:00 April 25 th ; Group 2, 1:00 April 25 th ; Group 9, 12:00 April 26 th ; Group 5, 1:00 April 26 th ; Group 6, 10:00 April 29 th ; Group 11, 12:00 April 29 th ; Group 8886, 1:00 April 29 th ; Group 7, 2:00 April 29 th ; Group 4, 3:00 April 29 th ; Group 10, 2:00 May 3 rd ; Group 1984, 3:00 May 3 rd.

Semester Summary - Topics lLarge vs. Small Systems – scale lSoftware lifecycle lSW reuse. Tools. lProgramming as a group activity lSW Testing lDocumentation lLegal issues lSecurity

Large vs. Small Systems – scale lWe (still) only have a rough idea of metrics lMain notion is “complexity” lSoftware becomes (potentially) more of a management issue as scale grows lWhat does “open source” suggest about how to cope with scale?

Software lifecycle lDesign, Implement, Test, Maintain lMaintenance longest portion of lifetime lBad design and implementation amplifies costs downstream lBrooks rule: 1/3, 1/6, ½ l90% of lifetime is maintenance lRelationship to costs

Software Reuse and Tools lReuse of general-purpose components lDesirable to not redo hard (& $$) work lTools enable better practices Version Control Systems (SCCS, RCS, CVS) Configuration Management (Make, config) Strong typing (ML) and Model Checking

Programming as a group activity l2 (somewhat polar) Models: Chief Programmer Team Corporation-emulating architecture Hierarchical, use of specialization “Egoless Programming” programming group Free criticism, “group think” Vaguely reappearing in “open source”

Software Testing lHard at the extreme – infinite tests lTest most common usages of system lIndependent testing groups lContinuous testing as at Microsoft, and in the “Open Source” methodology lWhere to involve users? (MS: early) lIs “many eyes” hypothesis true?

Documentation lCan take many forms: manuals, comments, built-in help, error messages lEssential to both users and builders lUsers: expose features, refine usage, increase usage, reduce MRs lBuilders: record design decisions, such as motivations for particular algorithm or data structures lDislike of documentation…

Legal Issues lUnderstand Liability lDifference between contract and tort lNotion of “best practice” lUnderstand “Intellectual Property” lPatent, Copyright and Trade Secret lIP rights, corporate and personal

Security l“Right information to the right people in the right place at the right time” lMuch like reliability lIncreasing important w/networks lMust be designed in lSemester project example approach lHow does development methodology affect software security?

Review my “central question”: lIf you want to build a VERY complex system, are you better off Enhancing a “super-programmer”? Managing an “army of ants”? What does Microsoft experience suggest? Open Source experience? Your own experience in this course?