Unformatted text preview:

CS427: Software Engineering IProject gradingGrade curve from 2001Topics since midtermOpen sourceSlide 6ProcessSlide 8The leaderThe usersRequirementsDesignTestingLife-cycleRewardsCommercial rewardsCostsEnablersXPSummaryNext time1CS427:Software Engineering IDarko Marinov(slides from Ralph Johnson)CS427 24-2Project gradingFinal report due on Dec 7Demo scheduled between Dec 4 and 18?The sooner the betterDefault: Everyone on team gets the same grade for the projectBUT: We will also ask you for more inputPrevious semesters: Individual project grades ranged from 0 to over the team gradeCS427 24-3Grade curve from 2001A+ 7A 15A- 27B+ 19B 13B- 11C+ 4C 1CS427 24-4Topics since midtermSpecificationsDesignQuality assuranceUser interfaceTwo more processesOpen source (today)Crystal light (next lecture)CS427 24-5Open sourceReading for this lectureThe Cathedral and the Bazaarhttp://catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/Source code is availableFor inspectionIndependent peer review Rapid evolutionCS427 24-6Open sourceTechnologyInternet (communication)Widely used languages Lots of potential users/helpersStandardsProcessCS427 24-7ProcessCathedral vs. bazaarCentralized vs. decentralizedPlanned vs. unplannedCS427 24-8Open sourceRolesLeaderDevelops initial systemDoes what nobody else doesMakes final decisionsUser/programmerDoes most of the workCS427 24-9The leaderAn open source project needs a leaderDelegates as much as he canEmpowers usersDecides what goes inCS427 24-10The usersUsers are co-developersUsers are programmers who can Add featuresFix bugsPort to new hardware/operating systemsImprove designCS427 24-11RequirementsWho decides what features get added?ProgrammersWho want to use the feature (scratch an itch)Who are persuaded to add itMust be a way to distribute changes for a featureMust be way to talk about desired featuresCS427 24-12DesignDesign is incrementalRefactoring is importantCS427 24-13TestingEvery user is a testerEvery programmer is a reviewer and bug fixer“Given enough eyeballs, all bugs are shallow.”“More users find more bugs.”CS427 24-14Life-cyclePlausible promise - must start with a (small) working programRelease early and oftenRecognize good ideas from usersKeep users connected, let them see the results of their workCS427 24-15RewardsWhy would anybody do this?They need the programEgo boostContributingHaving people think they are goodCS427 24-16Commercial rewardsWhy would anybody do this?Produce better softwareProduce software more cheaplyCS427 24-17CostsNeed a leaderA lot of work over a long timeMust communicateAn organizer as much as a designerCS427 24-18EnablersInternetCopyleftCBoring, high-paying jobsCS427 24-19XPHow is the “Bazaar” process like XP?Is the Bazaar leader like an XP customer?What about unit tests?Where does planning happen in the Bazaar?What could the Bazaar borrow from XP?What could XP borrow from the Bazaar?CS427 24-20Summary“Human beings take pleasure in a task when it falls in an optimal-challenge zone; not so easy as to be boring, not too hard to achieve.” “A happy programmer is one who is neither underutilized nor weighed down with ill-formulated goals and stressful process friction.” “Enjoyment predicts efficiency.”CS427 24-21Next timeCrystal Clear by Alistair CockburnReading will be updated on Wiki and sent to


View Full Document

U of I CS 427 - Software Engineering I

Download Software Engineering I
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 Software Engineering I 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 Software Engineering I 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?