1 Week 11 Software Engineering Spring Term 2016 Marymount University School of Business Administration Professor Suydam

2 Review/Critique of MP3 CS4/MP4 Preparation Project Budget (MS Excel) MS Project Study Guide Part 1 MS Project Project Planning Configuration Management Testing Planning Chapter 12 Software Support and Maintenance Quiz 3

3

4 SRS Add an Appendix C & D section to Case Study SRS. Download Test Plan template and incorporate in SRS space for Appendix C Appendix D will be text describing screen captures of MS Project document Download each of the hypertext linked documents to a working folder for CS4 Begin working with MS Project Software Project template adapting to your team project (using knowledge from MS Project VTCs)

5 Week 11 e-syllabus Group1Group2

6 MP4 Project Plan Component - Modify the sample MS Project Software Development Plan for your project for the following (make schedule realistic, modify dates, add/eliminate tasks, and assign responsibility) Analysis/Software Requirements (group of tasks) Design (group of tasks) Develop Preliminary Budget (See next slide -- Excel document) A screen capture, with accompanying introductory/explanatory text, will be your Appendix D (tap on figure below to download template).

7 MP4 Project Plan Component - Modify the sample MS Excel Budget Plan for your project (tap on figure below to download template).

8

9 MP4 Test Plan Component – Modify model for your project and attach to your SRS as Appendix C (figure below is linked to complete example)

10

Software Released! Now what?

12 Post software product-release support Non-defect support Usage questions-answers General help (install, recovery, etc.) Additional and supplemental functions (future releases) Defect support Report and track failure and defect Recovery from failure Work around Fixes releases While both non-defect and defect support are important, defect support requires some sophistication: o Project the # of problems and problem arrival rate o Estimate and plan the needed support resources o Educate and build the defect support team o Defect reporting and tracking o Defect identification, fix, and release

13 Traditionally follow a Raleigh Curve: A special case of Weibull distribution : f(t) = (m/t) (t/c) m e (-t/c)m [ note : m is a superscript to (-t/c) ] when m = 2, we have Rayleigh curve f(t) = (2/t) (t/c) 2 e (-t/c)2

14 Sunsetting Stop any product’s additional feature and enhancement Fix only the high severity problems Announce new replacement product Encourage new and existing customers to move to new product Notify all old users on the old product of the planned termination date Provide names of other vendors who are willing to support the old product to the customers who chooses to stay Terminate the customer product and withdraw the product from market

15 Software support is not free –Typical annual fee (e.g. 18% of product) Software support is not forever Most product goes through a number of releases Each product release is only supported for a limited number of years Customers/users are moved from back-level software to the current release as soon as possible -- Usually support no more than 2 back- levels of a software Tiered Customer Support -- organize the support group into tiers: A direct customer contact tier to accept problems, prioritize the problems, record problem, solve the “easy” problems, and manage the problem-resolution cycle. A higher tier pf specialized resource that sometimes talk to customers to resolve more difficult problems with work-arounds A tier of experts that can fix and rebuild the code

A key parameter in keeping the customers satisfied is to turn the problem fixes around within some reasonable time-frame. This requires an understanding and a “contract” of service terms. The contract on fix response time is in turn dependent on the types of problem based on some “prioritization” scheme

18 Customers do not always install a fix release provided by the software support group. Choose and pick the fixes they want Modified code and can not apply the generic fix release Stay on some past release because it “finally” works Need to explain the potential serious problem Fix Release related to other fix releases that customer care about in product fix situation. (see next slide) A released fix may have reworked over a previous “emergency’ fix code area (see a later slide) Multiple-Product Fix Releases that must be applied together to keep all the functions and data in synch Multiple-Product Fix Releases that must be applied together to keep all the functions and data in synch

20 All problems reported need to be tracked through successful problem- resolution with the customers. A part of this control is to ensure that all changes, for fixes and for enhancements, are not arbitrary and capricious. Change Control is the mechanism used, just as in software development prior to release, to ensure that all changes are managed through Change control process Documented changes (change control form as an aid) Change control committee

Manages the changes via a work flow: Origination of change request Approval of change request Monitoring the changes being made Closing the completed change Needs resource to ensure the control process: Change control board or committee Automated workflow tool (using a change control form)

22

23 1. List three customer support functions that a customer support/service organization performs. Ans: There are many customer support functions performed by support/service organization; some of the more common ones include 1) taking/recording/checking the name and identification of customer to ensure that the person is a legitimate customer, 2) listen to and record the problem, 3) answer the question if the solution is known or search the FAQ database for an answer, include providing an expected fix data if the problem is yet unresolved. Page: Explain the customer problem arrival curve in terms of customer usage of the product and the fixes. Ans: Customer problem arrival rate is directly related to the customer problem discovery rate. The rate of customer problem discovery is proportional to the amount of usage the software is experiencing. For example, a new software that has not been run often will not have much usage-time and the discovery of software problems will be relatively low. As the usage-time increases, the discovery of defects increases accordingly. After a period of time, the discovered problems will be fixed and all the major areas of software would have been exercised. Thus the discovery rate of defects will once again become low after a period of heavy usage and problem fixes. The graphical curve of this rise of problem discovery and problem arrival with increase in usage-time followed by a gradual decrease of problem discovery may be modeled with a Rayleigh curve. Page: What is the formula for usage month? Ans: Usage-month is a metric used to measure the amount of usage a software has gone through. Usage month is usually defined as (usage months = number of users actively using the software x number of months of usage). This metric, when combined with problems discovered, is often used in the assessment of software quality. Page: 251

24 4. What is a pre-requisite/co-requisite relationship of product maintenance and fix releases? Ans: There are times, a software S1 fix release also requires a fix release of another software S2 because S1 and S2 are related. An example may be where a change in S1 application requires an additional modification of a feature in S2. In this case the two software S1 and S2 modifications may be considered as co-requisites that must be released together or S2 modification is a pre-requisite that must be available first before S1 change may be released. Page: What is a problem priority level? What is it used for? Ans: A problem priority level is a metric that gauges and categorizes the severity level of a reported software problem. It is used to prioritize the problem fixing task and provide a rough estimate of problem fix-response time to the customer. Page: Describe the steps involved when a customer problem is passed from the customer service/support representative to the technical problem/fix analyst until the problem is resolved. Ans: There are several steps involved and they are summarized as follows. a) problem description and related information is summarized in a problem report and submitted to the problem/fix group; b) the problem/fix analyst will explore and analyze the problem; c) the problem/fix analyst will then accept or reject the problem based on the analysis; d) if the problem is rejected then the customer support representative is notified; otherwise, the problem is accepted, a change request is generated and the problem enters a fix cycle of design/code/test; e) the fix may be individually packaged and immediately released or may be integrated into a fix-release package, depending on the problem priority level; f) the support FAQ database is then updated to reflect the closure status of this problem. Page: 255

25 7. Give an example of a problem that may occur if a customer stays on a particular release, skips several maintenance/fix releases, and then applies a fix release. Ans: Skipping fix releases may cause a problem, especially if the fixes may be related. Consider a case where a variable is newly defined in a fix a, then it is again updated in a later fix b. If one skips these fix releases a and b, but apply a fix c that utilizes this newly introduced variable, fix c will not work. Page: What is the estimated effort field on the change request form used for? Ans: The estimated effort is used mostly for estimating the resource needed and for scheduling the completion and release date of the change or fix. Page: