1 / 47

Software Development Processes

Software Development Processes. Kun Niu Spring, 2011 April 7 th 05-899D Human Aspects of Software Development (HASD). The Information Networking Institute is a cooperative endeavor of: College of Engineering School of Computer Science Tepper School of Business Heinz College. Agenda.

grant
Download Presentation

Software Development Processes

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Development Processes Kun Niu Spring, 2011 April 7th 05-899D Human Aspects of Software Development (HASD) The Information Networking Institute is a cooperative endeavor of: College of Engineering School of Computer Science Tepper School of Business Heinz College

  2. Agenda • Definition • Software Development Lifecycle • Software Programming Process • Software Development Activity • Summary

  3. Agenda • Definition

  4. Definition • Software Development Lifecycle - Also known as a software development process, is a structure imposed on the development of a software product. (Agile, Waterfall, etc.)[Wikipedia] • Software Programming Process - The process of designing, writing, testing, debugging / troubleshooting, and maintaining the source code of computer programs (Test Driven Development, Model Driven Development, etc.) • Software Development Activity - Detailed technique used in software programming process (Pair programming, Rubber duck debugging, etc.)

  5. Why do people do research in these fields? • Improve the probability of project success – Software development lifecycle • Improve the productivity of the whole programming processes – Software programming process • Improve the productivity of a specific phase of software programming process – Software programming activity

  6. Agenda • Definition • Software Development Lifecycle

  7. Usage and Perceptions of Agile Software Development in an Industrial Context: An Exploratory Study [Begel, 2007] • Contribution • Try to understand how Agile Software Development methodologies are used in large scale industry • Dominant agile practices and methodologies • Common benefits and problems associated with ASD

  8. Exploratory Study Design • A web-based survey • Email to 2,821 recipients out of 28,000 • Demographic (response) • 18% for developers • 18% for testers • 10% for managers • Average 9.2 years of software development experience (0 - 35 y) • Survey Design • Survey sections: Demographic, Agile development, Pair programming • Card sort: free response for benefits and issues

  9. Collocation Data Use Agile? Collocated dynamics Yes No Not-collocated 12 29 Same country 4 10 Same city 1 2 Same campus 8 12 Same building 24 35 Same floor 68 138 Same hallway 25 76 Same office 14 18 Total 156 321 Many respondents using Agile of survey collocate in the same place

  10. Methodologies used

  11. Practices used

  12. Team attitudes and morale factors 60% people agree Agile work well for them and their team. Less than 40% people think Agile can work for large groups.

  13. Problems Benefits and problems Benefits Why not use?

  14. Threats to validity • Participants bias • Unknown team size and group size • Difficult to generalize because of different Microsoft’s product context

  15. Rapid Software Developmentthrough Team Collocation [Stephanie, 2002] • A field study conducted at a fortune 500 auto mobile company • Collocated software development team using Rapid Software Development Center • Six projects from different areas of the company • Prototyping, iterative development using “timeboxing” • Report by a combination of case study and empirical evaluation

  16. Room Layout

  17. Measures • Productivity Metrics • Function points normalized by certified Functional Points Foundation Group Member • Cycle Time • Number of months per 1000 functions • User Satisfaction • Composite of factors like ease of use, system performance etc. • Measures of Team Experiences • How often they will use rooms and hoteling space, conference room

  18. Measure results(pilot teams) Productivity Measures Satisfaction Measures

  19. Measure results (with subsequent team) Productivity Measures Satisfaction Measures Entry versus Exit questionnaire data

  20. Conclution • Benefits • Improve productivity (timeboxing and facilities) • Issues • Large projects • No accurate quality information • Don’t know if the increased productivity was due to Hawthorne

  21. Agenda • Definition • Software Development Lifecycle • Software Programming Process

  22. Test Driven Development

  23. Evaluating the Efficacy of Test-Driven Development: Industrial Case Studies • Bhat, 2006 from Microsoft • Two case studies, Windows and Messenger (A and B) Process timelines and defect density measurement Project organizations

  24. Case Study A Product measures Context Factors Outcome measures

  25. Case Study B Product measures Context Factors Outcome measures

  26. Result

  27. Threats to validity • High quality code resulted from a new process • Alleviated by the fact that all were professional programmers who had their own tasks • The projects may be easier and the comparison may be in accurate • Alleviated by the projects in the same organization and the complexity may be to the same degree • Hard to generalize in different environment and different contexts • The authors are trying to collect data from other TDD projects

  28. A Survey of Evidence for Test DrivenDevelopment in Academia • Chetan, 2008 • Surveys the current state of TDD experiments conducted at universities

  29. Misconceptions about TDD • You create a 100% regression test suite. • Not always cost-effective(UI) • Unit tests form 100% of your design specification. • Design document is necessary • You only need to unit test. • System integration test, performance test • TDD does not scale. • Divide into small suites

  30. Research conducted by someone else

  31. TDD introduction & learning • Introduction • Courses include • Explaining automated unit test • Describing TDD • Providing document • Supplying examples • Edward introduced at the beginning of the class, and used throughout the entire experiment • Reinforce may be a key • Learning • Incremental instructional approach • Test driven learning – Learn by example

  32. Conclusion • TDD exposes students to analytical and comprehension skills needed in software testing • TDD tends to help students with the design of complex projects, and increases student confidence. • Test-driven development reveals valuable software testing skills to fledgling programmers; the next step is figuring out how and when to introduce it into a curriculum.

  33. Agenda • Definition • Software Development Lifecycle • Software Programming Process • Software Development Activity

  34. The Social Dynamics of Pair Programming • Jan 2007 • The paper presents a series of pair programming interactions drawn from a long term ethnographic study of two software development teams • Term used in pair programming such as “driver” and “navigator” may not be right

  35. Pair programming history • Beck’s book <<Extreme Programming Explained>> There are two roles in each pair. One partner, the one with the keyboard and the mouse, is thinking about the best way to implement this method right here. The other partner is thinking more strategically: - Is this whole approach going to work? - What are some other test cases that might not work yet? • Is there some way to simplify the whole system so the current problem just disappears? • Few studies focuses on the nature of interactions

  36. Research • Four months ethnographic study • Two software development teams • Have a long history of pair programming

  37. Findings • Both software development teams differed greatly from the driver and navigator roles described in the academic and practitioner literature • When the two programmers had equivalent expertise, they engaged jointly in programmer activities. • When the distribution of task-relevant expertise differed, the programmer with more expertise dominated the interaction. • Keyboard control had a subtle, but consistent effect on decision making.

  38. Implication of the research • The pairs appeared to be most effective when both programmers took on driver and navigator responsibilities • Programmers felt more engaged in their tasks when they either had keyboard control or keyboard control was imminent • Expertise emerges as a particularly important factor influencing pair interactions • Pairing less knowledgeable programmers with more knowledge programmers did seem to be effective when the less knowledgeable programmer was new to the team and code base • Programming partner rotation appeared to be effective in ensuring increased dispersion of code knowledge across the team, rotating late in the task may break up an effectively functioning pair and introduce a new programmer in a disadvantaged position

  39. Pair Programming: What’s in it for Me? • Begel, 2008 • Report on a longitudinal evaluation of pair programming at Microsoft Corporation • Understand how pair programming methodologies are used, what kinds of problems and benefits they are perceived to have, the types of partners people would like to work, and a general consensus on PP‟s usefulness in the software engineering professional community • A web-based survey of Microsoft developers

  40. Contribution 1. Quantitative data on the adoption of pair programming in a large software company. 2. The perceived benefits and problems of pair programming. 3. The characteristics an engineer looks for in an ideal pair programming partner and team. 4. The perception that pair programming produces higher quality code at the expense

  41. Previous study result • Different universities have opposite results in PP research • Different industrial projects also have different result • Conclusion from the author • Pair programming appears to be very different in academic than in industry • In academia, pair programming is used for education and has positive effects on student retention. • In industry, there is little research on pair programming, and what little there is shows conflicting results. • No good qualitative assessment of how professional programmers might explain these results.

  42. Effect of Pair Programming on Work

  43. PP benefits & problems Benefits Problems

  44. Attributes of good programming partners and teams Attributes of Good Teams Attributes of Good Partners

  45. Agenda • Definition • Software Development Lifecycle • Software Programming Process • Software Development Activity • Summary

  46. Session Summary • Software development lifecycle • Tools tend to provide quantitative data to help manager’s judgment • How to generalize the result is still a problem (Can be solved?) • How to improve the accuracy of result? • Software programming process • TDD is a widely researched field both in industry and in academic • How to make people accommodate it is still a problem • Software development activity • Pair programming in XP is popular • Industry studies show difference real use and academic research

  47. Questions & Comments

More Related