1. Questions and support on assignment -------------------------------------- What are your current problems? 2. Semi-structured Interviews ----------------------------- Questionnaires and Surveys have pre-determined questions. Often with pre-determined answer alternatives. They are not given in person but on paper or via the web. Structured Interviews have pre-determined questions. Often also pre-determined follow-up questions. You stick to your questions as closely as possible and do not "get sidetracked". Unstructured Interviews do not have pre-determined questions. You sit down with an interviewee and discuss some topic(s). The discussion can take almost any direction depending on the interviewee. Semi-structured interviews are more formal than Unstructured but less formal than Structured. You often have pre-determined questions, but you allow yourself to go deeper into areas where the interviewee has interesting answers. Depending on the answers you can "improvise" more to get interesting knowledge. However, you still try to stay "on topic". To do this you need to be clear on the purpose with the interview and turn back to areas and questions that helps you fulfill that purpose. It is also important that the interviewee knows the purpose. Thus you should state that early in the interview. 3. Conducting an interview -------------------------- Before you conduct the interview you should (1&2): 1. Design the interview instrument - a doc you use to guide the interview a, Write down the purpose (3-5 sentences). Why are you doing these interviews? What is it that you want to get out of them? b, Write down a statement about how you will use the answers. Available to whom? Anonymous? If so, how? c, Write down fairly open-ended questions/issues/topics. 20 questions is often a good number for an hour of interview (but it depends on the detail of the questions!). They should "flow" logically from each other so that they are likely to come in roughly that order in the discussion. Questions are open when the interviewee has to express opinions and discuss their answers somewhat and cannot simply give short, factual answers. Of course you can have a mix of different types of qeustions. 2. Decide on the format for the interview a, Who will be posing questions? It is often best if one person acts as interviewer and 1-2 persons are more passive ("recorders"; see below) and only occasionally adds comments/questions as they see fit. b, How will you collect the answers? Either you record it or you have 1-2 people that writes down as much as possible of the answers / summarizes them. If you plan to record you have to ask the interviewee if it is ok. You also have to prepared to take written notes if they do not think it is ok. c, Try to have at least 10-15mins after an interview just to sit and summarize your impressions. Especially if you are taking written notes. Conducting the interview: 3. Be there on time and set everything up Be sure you are there at least 30 mins before. Check out the room. Set up audio recording equipment or position the chairs. It is often good that interviewer and interviewee sit fairly close together while the recorders can be more in the background. Try to avoid sitting on a long row as questioners and then the interviewee at a distance. 4. Welcome the person. Present yourself. Show them were to sit. Try to get them to feel ok with the situation. If possible do some jokes etc to make them "settle down" in the situation. 5. Explain the purpose of the interview. Overall purpose (form interview instrument) and goals, context in rest of study, what else you are doing to collect data. 6. Explain what you will do with the data. If you are recording audio ask them if it is ok. Ensure them that only you will have direct access to their answers. No one else at the company will ever get the exact answers etc. If no audio explain how you will handle the written notes. 7. Fire off your questions. Allow the interviewee time to expand and explain. Follow-up to dig deeper when you do not understand. Especially when their answer deviates from what you expected or have heard from others. You want to establish both what is similar and what is different from others views. Keep tab on the clock so that you know when to move on to other questions. 8. Have a very open-ended questions at the end. "So do you think we have missed any important issue when it comes to PURPOSE?" "Anything you want to add?" "What would be the most important improvements from your point of view?" 9. Thank them for their time. Explain what you will do next and when they should expect some result from your work. 4. Testing and SPL ------------------ Page 259, SPLIA Siemens Medical, 100 devs, +50% reuse level, -25% dev cycle time, -57% cost of quality X-ray, MRI, CT scanners - takes pictures SIENET COSMOS = picture archiving and communication system Focus: Reduce dev effort => Reduce testing effort (since QA costs are key in medical domain) 2 existing and similar products, 1 new coming up No management support to go for SPL, no time for separate domain and appl teams, learning etc Only key/inevitable activities from SPLE: commonality and variations. 2002-2003 introduced Scenario-Based Test case Derivation (SBTD): * scenario-based refinement of use cases to test cases * variability defined in RE and maintained to testing 1. Scenarios are expressed in UML activity diagrams Stereotypes "<>" can be used in Activities to restrict which products can have the variant. Optional activities can be specified in "parallel paths". 2. Domain test case scenarios keep variants in UML sequence diagrams 3. Application test cases start from DTCS and bind/restrict variability Lessons learned: * Variability has to be validated. Textual descriptions led to too much interpretations. Explicit modeling + discussion cleared up. 5. Challenges for SPL --------------------- Do not look at SPLE if your company: 1. single product version for a customer 2. different projects today than yesterday 3. each new product developed from scratch * Mostly applied to embedded systems, less experience from information systems. * All companies have to adapt a SPLE strategy, not enough general guidelines/experience available * Mostly large organisations. Some smaller but not many. * Lack of experiments and detailed comparisons. * Lack of business and cost models. * QA / testing often done like single-system dev. More research is needed. * Lack of support for SPL evolution. * Model-driven Architecture vs SPLE? * Future: End-user customisation, Adaptive systems on top of Open Architectures