1. Judy Stafford Comp 190 – Meeting 2 February 2, 2010 http://www.cs.tufts.edu/comp/190 Working to get it Right

2. COMP 1902 Agenda for the Evening  Thought Questions  Understanding what’s important  What’s next  Team Presentations  Team meetings

3. How does our situation differ  What is Ant, and how does it work?  Most of us in this class are working in small teams. To what size teams/projects do the following apply? –Version Control –Continuous Integration –Bug/Issue Tracker –Testing Harness  A theme in this book seems to be that developers and managers communicate and stay informed through a central hub, be it a version control system, bug tracker, or otherwise. Is it safe to say that this "hub model" tends to succeed, and that disconnects in communication are the main cause of failure?  Some of the suggestions (daily meetings) seem more appropriate for full- time developers/development. In circumstances, where software development is not a full time activity; what else can/should change or be dropped? COMP 1903

4. Tools – is best tool necessarily best?  Chapter two talks about picking tools to use to track issues, features, code changes and manage testing. The authors say that you should choose the best tool for the job, without talking too much about the learning curve for a particular tool. Should the difficulty of implementing a tool, and teaching it to everyone who needs it be an important question when choosing a tool, or will the greater benefits of a great tool outweigh any start up costs?  Can taking “Mike’s” approach to tool selection (find the best one for the job) to the extreme. It is easy to get lost in researching new tools and trying them out, all the while procrastinating the work. Though not a direct parallel, I particularly find it easy to get sidetracked on trying out new tools instead of concentrating on mastering the tools that I am using at the moment. Where is the right place to draw the line? How much time is reasonable to be doing this research into new tools? COMP 1904

5. Quality Attribute Workshops  Helps identify implicit requirements – these are often missed by developers  More projects fail due to missed requirements than poorly implemented ones  What happens – in a real setting the QAW takes much up front preparation by both the software organization and the evaluation team –Business goals are studied –Architectural plan is reviewed –Stakeholders are gathered  Workshop takes three days and includes about a dozen stakeholders plus the evaluation team COMP 1905

6. Focus on Getting it Right – Mock QAW  But, we’ll hit the high points –Pretend we’re stakeholders – what roles are appropriate? –Team will build on last week’s presentation giving updates on requirements and plans –Class will brainstorm scenarios (think of these as high level test cases –Collect as many as possible then team will organize and prioritize COMP 1906

7. 7 Team Presentations  But first … Next time: –Read Chapters 3 and 4 of Ship it! and submit thought questions to provide before Monday –Mock QAW (Quality Attribute Workshop) »Create presentation  Refined requirements – you might want to check in with your sponsor during the week  Your planned approach –Technologies –Architectural patterns –Software components and/or services »Goal is to hammer at the requirements by coming up with scenarios of how different people can imagine the system being created, used, maintained, evolved.  Now for the presentations