Software Engineering Spring Term 2017 Marymount University

Slides:



Advertisements
Similar presentations
Systems Development Environment
Advertisements

Software Configuration Management
SE 555 Software Requirements & Specification Requirements Management.
IS550: Software requirements engineering Dr. Azeddine Chikh 4. Validation and management.
Configuration Management
CEN th Lecture CEN 4021 Software Engineering II Instructor: Masoud Sadjadi Change Control.
This chapter is extracted from Sommerville’s slides. Text book chapter
Chapter 14 Information System Development
Systems Analysis and Design
Connecting with Computer Science2 Objectives Learn how software engineering is used to create applications Learn some of the different software engineering.
1 Chapter 12 Configuration management This chapter is extracted from Sommerville’s slides. Text book chapter 29 1.
Chapter 12 Software Support and Maintenance. Product released! Software Released! Now what?
T EST T OOLS U NIT VI This unit contains the overview of the test tools. Also prerequisites for applying these tools, tools selection and implementation.
BSBPMG501A Manage Project Integrative Processes Manage Project Integrative Processes Project Integration Processes – Part 2 Diploma of Project Management.
1 Week 11 Software Engineering Spring Term 2016 Marymount University School of Business Administration Professor Suydam.
1 Week 13 Software Engineering Fall Term 2016 Marymount University School of Business Administration Professor Suydam.
Chapter 25 – Configuration Management 1Chapter 25 Configuration management.
1 Requirements Management - II Lecture # Recap of Last Lecture We talked about requirements management and why is it necessary to manage requirements.
Systems Development Life Cycle
School of Business Administration Chap 3 Engineering of Software;
SharePoint 101 – An Overview of SharePoint 2010, 2013 and Office 365
ITIL: Service Transition
School of Business Administration
School of Business Administration
School of Business Administration
Software Configuration Management
Software Project Configuration Management
QAD Browses.
8.4 Management of Postdelivery Maintenance
Fundamentals of Information Systems, Sixth Edition
Archiving and Document Transfer Utilities
School of Business Administration
School of Business Administration
School of Business Administration
Approaches to ---Testing Software
Chapter 11: Software Configuration Management
Principles of Information Systems Eighth Edition
Presenter Name Presentation Date
Chapter 18 Maintaining Information Systems
MyStatLab Student help/instructions MTH/233
Maintaining software solutions
Maintaining Quality Test Optimization with Increasing Software Complexity Ankit Goyal Software Engineer II Adobe Systems.
Presentation Graphics
Presenter Name Presentation Date
Software Quality Engineering
Custom Workflow Template
Unit4 Customer Portal Submitting & Managing Cases.
Your Finance Cloud End User Adoption and Enablement Starts Here
SSI Toolbox Status Workbook Overview
IS&T Project Reviews September 9, 2004.
Chapter 2 – Software Processes
Presenter Name Presentation Date
Health Ingenuity Exchange - HingX
Chapter 9 – Software Evolution and Maintenance
Introducing ISTQB Agile Foundation Extending the ISTQB Program’s Support Further Presented by Rex Black, CTAL Copyright © 2014 ASTQB 1.
Chapter 11: Software Configuration Management
LESSON 01 Hands-on Training Execution
MODULE B - PROCESS SUBMODULES B1. Organizational Structure
MANAGING THE DEVELOPMENT AND PURCHASE OF INFORMATION SYSTEMS
Product released! Software Released! Now what?.
Systems Development Life Cycle
M. Kezunovic (P.I.) S. S. Luo D. Ristanovic Texas A&M University
Presenter Name Presentation Date
Presenter Name Presentation Date
System Analysis and Design:
Chapter 2: Building a System
Chapter 12: Software Support and Maintenance
Building a “System” Moving from writing a program to building a system. What’s the difference?! Complexity, size, complexity, size complexity Breadth.
Presentation transcript:

Software Engineering Spring Term 2017 Marymount University School of Business Administration Professor Suydam Week 11 Chapter 12 Software Support & Maintenance MP4 SRS App C&D

Agenda for Week 11 Review/Critique of CS3 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

CS3/MP3 Requirement/Weight Collaboration Diagram CS3 Comments CS3/MP3 Requirement/Weight “Inside Visio 2013” Page “UML Distilled” Page You Tube Video Runtime (min:sec) Data Flow Diagrams DFD (Context, DFD0, DFD1, DFD2) (30%) 583 None Context/DFD0 9:56 Static structure (class) diagram (10%) 593 36 Class Diagram 15:31 State chart diagram (10%) 598 108 State Chart Diagram 6:12 Sequence diagram (10%) 595 54 Sequence Diagram 11:17 Deployment diagram (10%) 601 98 Deployment Diagram 8:01 Component diagram (10%) 600 140 Component Diagram 17:51 Collaboration diagram (10%) (Note: create from Sequence Diagram) 599 144 Collaboration Diagram 0:51 Activity diagram (10%) 596 118 Activity Diagram 6:15

CS4/MP4 Preparation 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)

Week 11 e-syllabus

MS Project Study Guide Groups 1 & 2 (to be completed outside class) See Week 11 e-syllabus Group1 Group2 VTC w/”*” VTC w/”*” Chapter 2 ~41 minutes Chapter 3 ~42 minutes

MS Project – Project Planning Appendix D CS4/MP4 Project Plan Component (to download, in Slideshow mode, tap on figure below to download template, or Ctrl+click in Normal view) - 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 included in your Appendix D

MS Project – Project Budget (included with Appendix D) CS4/MP4 Project Plan Component - Modify the sample MS Excel Budget Plan for your project by highlighting any changes to template in red. To download, in Slideshow mode, tap on figure below to download template, or Ctrl+click in Normal view

Appendix D: Essential Test Plan

MS Project – Testing Planning Appendix C MP4 Test Plan Component – Modify model provided for your project and attach to your SRS as Appendix C (to download, in Slideshow mode, tap on figure below to download template, or Ctrl+click in Normal view)

Chapter 12

Product released! Software Released! Now what?

Customer/User Support 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: Project the # of problems and problem arrival rate Estimate and plan the needed support resources Educate and build the defect support team Defect reporting and tracking Defect identification, fix, and release

Problem Discovery Curve 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

Product Support Life Cycle & “Sun-setting” 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

Customer Support 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 Sample Service and Support Organization

Problem Fixes and Priority Levels 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

Installing Fixes 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

Fix Overlay Problem

Change Control in Support & Maintenance 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

Change Control Process and Committee, & Maintenance Change Request Form 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)

Chapter 12 Summary & Review Questions

Chapter 12 Summary & Review Questions 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: taking/recording/checking the name and identification of customer to ensure that the person is a legitimate customer, listen to and record the problem, 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: 250-251 2. 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: 251-254 3. 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

Chapter 12 Summary & Review Questions 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: 260 5. 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: 254 6. 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

Chapter 12 Summary & Review Questions 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: 256-258 8. 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: 259-260