New User Special Price Expires in

Let's log you in.

Sign in with Facebook


Don't have a StudySoup account? Create one here!


Create a StudySoup account

Be part of our community, it's free to join!

Sign up with Facebook


Create your account
By creating an account you agree to StudySoup's terms and conditions and privacy policy

Already have a StudySoup account? Login here

Research Seminar III

by: Kiera Waelchi

Research Seminar III DCS 891C

Kiera Waelchi

GPA 3.57


Almost Ready


These notes were just uploaded, and will be ready to view shortly.

Purchase these notes here, or revisit this page.

Either way, we'll remind you when they're ready :)

Preview These Notes for FREE

Get a free preview of these Notes, just enter your email below.

Unlock Preview
Unlock Preview

Preview these materials now for free

Why put in your email? Get access to more of this material and other relevant free materials for your school

View Preview

About this Document

Class Notes
25 ?




Popular in Course

Popular in Doctoral Computing Studies

This 12 page Class Notes was uploaded by Kiera Waelchi on Wednesday September 30, 2015. The Class Notes belongs to DCS 891C at Pace University - New York taught by Staff in Fall. Since its upload, it has received 31 views. For similar materials see /class/217092/dcs-891c-pace-university-new-york in Doctoral Computing Studies at Pace University - New York.

Popular in Doctoral Computing Studies


Reviews for Research Seminar III


Report this Material


What is Karma?


Karma is the currency of StudySoup.

You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!

Date Created: 09/30/15
Overview of A Structured Experiment of TestDriven Development Jim Kile What is this paper about 0 Problem explored To empirically analyze and quantify the effectiveness of TestDriven Development TDD 0 Why Unless objects are designed judiciously dependency problems eg tight coupling fragile super classes etc can creep into code affecting code quality TDD proponents argue that reduced coupling occurs because the practice guides them to 0 Build only those objects that are actually needed 0 Improves code quality through continuous testing There is no empirical evidence to support the claims made by proponents June 24 2005 DCSSQ lC Summer 2005 What is this paper about 0 Hypotheses The TDD practice will yield code with superior external code quality when compared with code developed in a waterfalllike practice Programmers who practice TDD will develop code faster than programmers who develop code with a more traditional waterfall like practice 0 Results TDD appears to yield code with superior external code quality TDD programmers took more time 16 than control group programmers On average 80 of professional programmers thought TDD was effective and 78 believed productivity was improved TDD facilitates simpler design and the lack of upfront design is not a hindrance June 24 2005 DCSSQ lC Summer 2005 Technical background What is testdriven development A practice of software development that involves the implementation of a system starting from the unit test cases of an object If you can t write a test for what you are about to code then you shouldn t even be thinking about coding 21 o Perceived shortcomings Lack of upfront design Applicability of practice for code that is difficult to test using TDD eg GUls Reliance on refactoring to achieve code understanding and manage complexity High skill level and experience requirements 0 Perceived benefits Program comprehension especially useful for maintenance activities Efficiency through continuous feedback Creation and availability of reusable test assets Reducing defect injection during development June 24 2005 DCSSQ lC Summer 2005 Context of this research Experiments were done with practitioners in their own working environment 0 Sample size was relatively small 0 Experiment was modified after the first trial 0 All programmers worked in pairs John Deere and RoleModel had used pair programming Ericcson was introduced to pair programming 0 The code generated was very small 200 L00 0 Subjects had varying levels of experience quot June 24 2005 DCSSQ IC Summer 2005 Research approach o Experimentation quantitative A set of three structured experiments conducted with 24 pair programmers 0 One group developed using TestDriven Development 0 Another control group developed using a waterfalllike approach Results monitored for black box test cases passed time taken to complete and percentage of code coverage 0 Survey qualitative A set of nine closeended questions aimed at eliciting opinions about 0 How productive the practice is for programmers o How effective is the practice 0 How difficult is the practice to adopt June 24 2005 DCSSQ IC Summer 2005 Related research problems ideas 0 IDEA 1 Conduct a larger scale study along the same lines Sample size was small in this study and though statistically there were correlations one ofthe three experiments had to be thrown out o IDEA 2 Further analyze if TDD can have a positive impact on productivity This research proved there was a positive correlation between TDD and quality deliverables Quality can yield future savings and productivity Hypotheses There is a learning curve when introducing TDD methods to a team For small w duration efforts this learning curve will impact productivity Longer efforts should see productivity equal to or superior to a waterfall baseline Note This can be done in pair fashion as was done here or in nonpair fashion though interestingly nonpair studies to date seem to have better results 0 IDEA 3 Analyze enhancement projects where the original project followed TDD and there Is a base of test cases for regressron M Hypotheses TDD provides a positive impact on development productivity when l the initial project uses TDD and those regression cases are available for I a subsequent enhancement project o IDEA 4 Rerun the study using individual programmers rather than pairs The study required people to be familiar with a programming technique which is not in wide usage in the industry Signi cance Is there any bene t to doing TDD in existing work environments 392 without introducing pair programming June 24 2005 DCSSQ IC Summer 2005 Further analyze TDD prOdUCtiVity impact idea 2 Other studies using students did find the practice to be neutral to productivity 3 This same study indicated that the vast majority of test subjects on average had only 4 months experience with Java or 0 Only one individual had set development practicesquot There was no productivity improvement or reduction using TDD in this environment productivityneutral o The conclusion expressed confusion at the results they were also expecting productivity improvement 0 This could that the practice is productivity neutral once the learning curve is overcome however Still other studies using professional programmers found the practice to be neutral or a slight impact on productivity This study did not use a control group during the actual experiment but used adhoc testing ofa similar prior project as a basis 0 None of these studies used pair programming but used traditional programming June 24 2005 DCSSQ1C Summer 2005 Productivity for enhancement projects using TDD idea 3 o A couple of studies have indicated the potential for productivity improvements for future enhancement projects 3 Work to create a base of automated unit test cases would be complete There would need to be time spent to update automated cases with the enhancements o This doesn t seem to have a lot of existing studies most do not go a second step to record enhancement productivity June 24 2005 DCSSQ IC Summer 2005 Presentation references P1 B George and L Williams quotAn Initial Investigation of test Driven Development in Industryquot Proceedings of the 2003 ACM Symposium on Applied Computing pp 11351139 Melbourne Florida UASA ACM Press 2003 P2 E M Maximilien and L Williams quotAssessing testdriven development at IBM Proceedings of the 25th International Conference on Software Engineering pp 564569 Portland Oregon USA IEEE Computer Society 2003 P3 D Staff and M G Ernst quotAn Experimental Evaluation of Continuous Testing During Developmentquot Proceedings of the 2004 ACM SIGSOFT International Symposium on Software Testing and Analysis pp 7685 Boston Massachusetts USA ACM Press 2004 P4 L Williams E M Maximilien and M Vouk quotTestDriven Development as a DefectReduction Practicequot 14th International Symposium on Software Reliability Engineering p 34 Denver Colorodo USA IEEE Computer Society 2003 November 2003 June 24 2005 DCSSQ IC Summer 2005 Original references 1 K Beck Extreme Programming Explained Embrace Change Reading Massachusetts AddisonWesley 2000 2 K Beck Test Driven Development By Example Addison Wesley 2002 3 K Beck quotAim Firequot in lEEE Software vol 18 SeptemberOctober2001 pp 8789 4 F P Brooks The MythicalManMonth AddisonWesley Publishing Company 1995 5 D T Campbell and J C Stanley Experimental and QuasiExperimental Design for Research Boston Houghton Mifflin Co 1963 6 D Chaplin quotTest First Programmingquot TechZone 2001 7 T A Corbi quotProgram Understanding challenge for the 1990squot IBM Systems Journal vol 28 pp 294306 1989 8 S Cornett quotCode Coverage Analysisquot Bullseye Testing Technology 2002 9 B Foote and J Yoder quotBig Ball of Mudquot presented at Fourth Conference on Patterns Languages of Programs Monticello Illinois September 1997 10 D Gelperin and W Hetzel quotSoftware Quality Engineeringquot presented at Fourth International Conference on Software Testing Washington DC June 1987 11 B George quotAnalysis and Quantification of Test Driven Development Approach MS Thesisquot in Computer Science Raleigh NC North Carolina State University 2002 12 D Hamlet and J Maybee The Engineering of Software Boston Addison Wesley 2001 June 24 2005 DCSS91C Summer 2005 Original references Continued 13 W S Humphrey Managing the Software Process Reading Massachusetts AddisonWesley 1989 14 C Larman and V Basili quotA History of Iterative and Incremental Developmentquot IEEE Computer vol 36 pp 4756 June 2003 15 M M Lehman and L Belady Program Evolution Processes of Software Change London Academic Press 19 5 16 C R Martin Advanced Principles Patterns and Process ofSoftware Development Prentice Hall 2001 in s 17 E MMaltimilien and L V lliams quotAssessing Testdriven Development at IBMquot presented at International Conference of Software Engineering Portland OR 2003 18 M M Muller and O Hagner quotExperiment about Testfirst programmingquot presented at Empirical Assessment In Software Engineering EASE 3902 Keele April 2002 19 D E Perry and A L Wolf quotFoundations forthe Study of Software Architecturequot ACM SIGSOFT vol 17 pp 4052 October 1992 20 W W Royce quotManaging the development of large software systems concepts and techniquesquot presented at IEEE WESTCON Los Angeles CA 1970 21 A vanDeursen quotProgram Comprehension Risks and Opportunities in Extreme Programmingquot CWI Amsterdam SENR0110 ISSN 1386369X 2001 22 A vanDeursen L Moonen A vandenBergh and G K R t code quotRefactoring test codequot presented at XP 2 1 23 L V lliams E M Maximilien and M Vouk quotTestDriven Development as a DefectReduction Practicequot presented at IEEE International Symposium on Software Reliability Engineering Denver CO 2003 24 L A V liams The Collaborative Software Process Salt Lake City UT Department of Computer Science 2000 June 24 2005 D088910 Summer 2005


Buy Material

Are you sure you want to buy this material for

25 Karma

Buy Material

BOOM! Enjoy Your Free Notes!

We've added these Notes to your profile, click here to view them now.


You're already Subscribed!

Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'

Why people love StudySoup

Bentley McCaw University of Florida

"I was shooting for a perfect 4.0 GPA this semester. Having StudySoup as a study aid was critical to helping me achieve my goal...and I nailed it!"

Amaris Trozzo George Washington University

"I made $350 in just two days after posting my first study guide."

Jim McGreen Ohio University

"Knowing I can count on the Elite Notetaker in my class allows me to focus on what the professor is saying instead of just scribbling notes the whole time and falling behind."

Parker Thompson 500 Startups

"It's a great way for students to improve their educational experience and it seemed like a product that everybody wants, so all the people participating are winning."

Become an Elite Notetaker and start selling your notes online!

Refund Policy


All subscriptions to StudySoup are paid in full at the time of subscribing. To change your credit card information or to cancel your subscription, go to "Edit Settings". All credit card information will be available there. If you should decide to cancel your subscription, it will continue to be valid until the next payment period, as all payments for the current period were made in advance. For special circumstances, please email


StudySoup has more than 1 million course-specific study resources to help students study smarter. If you’re having trouble finding what you’re looking for, our customer support team can help you find what you need! Feel free to contact them here:

Recurring Subscriptions: If you have canceled your recurring subscription on the day of renewal and have not downloaded any documents, you may request a refund by submitting an email to

Satisfaction Guarantee: If you’re not satisfied with your subscription, you can contact us for further help. Contact must be made within 3 business days of your subscription purchase and your refund request will be subject for review.

Please Note: Refunds can never be provided more than 30 days after the initial purchase date regardless of your activity on the site.