Presentation is loading. Please wait.

Presentation is loading. Please wait.

CS 577b: Software Engineering II

Similar presentations


Presentation on theme: "CS 577b: Software Engineering II"— Presentation transcript:

1 CS 577b: Software Engineering II
CS 577b Software Engineering II -- Introduction 1 April 2017 CS 577b: Software Engineering II Class Introduction © USC Center for Software Engineering

2 Outline Schedule Marks Allocation Possible 577b risks
Guest Lecturers TechTalk Pair Research Presentation Marks Allocation Possible 577b risks Team Re-Formation (C)USC-CSSE

3 CS 577b Software Engineering II -- Introduction
1 April 2017 Course Schedule See Class settings 6:40pm – 8pm: Lecture 8:15pm – 9:20pm: Class Activities No Class, but team presentations/reviews on Rebaselined DC ARB – Week of 02/12 Design Code Review – Week of 03/05 Core Capability Drivethrough – Week of 03/26 Transition Readiness Review – Week of 04/16 (C)USC-CSSE © USC Center for Software Engineering

4 CS 577b Software Engineering II -- Introduction
1 April 2017 Milestone Reviews Rebaselined Development Commitment Review Design Code Review Core Capability Drive thru Transition Readiness Review © USC Center for Software Engineering

5 Technology Interchange Meeting Retrospective meeting
Milestone review Design Review Code Review Sprint Review Technology Interchange Meeting Retrospective meeting ©USC-CSSE

6 The Incremental Commitment Spiral Model
This slide shows the overall concept of the ICM Commitment and accountability Success-critical stakeholder satisficing, Incremental growth of system definition and stakeholder commitment, Concurrent engineering, Iterative development cycles, Risk-based activity levels and milestones ©USC-CSSE

7 ICSM –Class Milestones
2/12 3/26 4/16 4/30 3/5 Code Review (C)USC-CSSE

8 (C)USC-CSSE

9 ARB Review Success Criteria
FCR DCR For at least one architecture, a system built to arch. will: • Support the Ops Concept • Satisfy the Requirements • Be faithful to the Prototype • Be buildable within the budgets and schedules in the Plan • Show viable business case Key stakeholders committed to support Foundations Phase (to DCR) For the selected architecture, a system built to the arch. will: All major risks resolved or covered by risk management plan Key stakeholders committed to support full life cycle 4

10 Commitment Review Success Criteria
CCD TRR / OCR Determine whether client needs anything further to ensure successful Transition and Operation Changes in priorities for remaining features? Changes being made to operational procedures? More materials needed for training? Changes in system data or environment we should prepare for? Anyone else who should experience CCD? Show value Product works as expected (or not with noted exceptions) Product will help users do job Show quality development e.g. relevant parts of your IOC documentation Process Show sustainability e.g. support requirements/plans Transition plan & status Show confidence that product is/will be ready to be used e.g. Transition plan & status See also value

11 ARB Session Outline RDCR similar format to DCR, different focus:
More time on changes and updates More time for Architecture, Plans General rule on focus: emphasize your projects high risk areas At FCR (in most cases) this will involve establishing the operational concept (including system analysis) At DCR (in most cases) this will involve the system design and development plan (especially schedule) At RDCR this will involve the system design and development plan and test plan 11

12 RDCR ARB topics Topics to cover in your presentation & recommended time allocations Summary of Change Sources & Resulting Changes Progress of Prototype Construction Plans; Transition Plan Draft General Discussions Risk analysis to determine course of actions

13 RDCR ARB – Architected Agile Teams
(x,y): (presentation time, total time) (8, 10) Acceptance Test Plan and Cases; Team's strong and weak points + Shaping & Overall Project Evaluation; Full test plan and cases (2, 3) OCD. System purpose; changes in current system and deficiencies, proposed new system, system boundary, and desired capabilities and goals; top-level scenarios (10,15) Prototype Update. Changes in significant capabilities (especially those with high risk if gotten wrong) (8, 10) Architecture. Overall and detailed architecture; design if critical; COTS/reuse selections (NOT JUST CHOICES) (6, 8) Life Cycle Plan. At lease until CCD or as appropriate; Include plans for CTS Team members’ roles & responsibilities in 577b, Full Iteration Plan (5, 10) Feasibility Evidence. Focus on Risk Analysis. Traceability Matrix. Definition of Done, Metrics • Plan on 2 minutes per briefing chart, except title • Focus on changes (particularly new things) since DCR • You may vary from the above: please notify ARB board members IN ADVANCE • QFP & QMP not presented/discussed due to time constraints.

14 RDCR ARB – NDI-intensive Teams
(x,y): (presentation time, total time) (8, 10) Acceptance Test Plan and Cases; Team's strong and weak points + Shaping & Overall Project Evaluation; Full test plan and cases (2, 3) OCD. System purpose; changes in current system and deficiencies, proposed new system, system boundary, and desired capabilities and goals; top-level scenarios (10,15) Prototype Update. Changes in significant capabilities (especially those with high risk if gotten wrong) (5,7) Architecture. Overall and detailed architecture; design if critical; COTS/reuse selections (NOT JUST CHOICES) (6, 8) Life Cycle Plan. At lease until CCD or as appropriate; Include plans for CTS Team members’ roles & responsibilities in 577b, Full Iteration Plan (5, 10) Feasibility Evidence. Focus on Risk Analysis, Traceability Matrix. Definition of Done, Metrics • Plan on 2 minutes per briefing chart, except title • Focus on changes (particularly new things) since DCR • You may vary from the above: please notify ARB board members IN ADVANCE • QFP & QMP not presented/discussed due to time constraints. 14

15 Grading Guidelines Total = 50 points (20) Progress of your work
(10) Presentation (5) Risk Management (15) Quality 4/2/2012 (C) USC-CSSE

16 Milestone review tasks
Prepare for milestone review Set scope Schedule review meeting Distribute meeting materials Conduct review meeting Progress, Quality, risk profile, feasibility Record decision ©USC-CSSE

17 CS 577b Software Engineering II -- Introduction
1 April 2017 Milestone Reviews Rebaselined Development Commitment Review Design Code Review Core Capability Drive thru Transition Readiness Review © USC Center for Software Engineering

18 ©USC-CSSE

19 Internal Code Review ©USC-CSSE

20 Outline Problems & Motivation Faithful vs. Unfaithful
Preparation and Review Process 4/2/2012 (C) USC-CSSE

21 Motivation To aid with successful transition
Ensure that implementation is faithful to the design Or at least consistent Sufficient documentation for maintenance period Ease software understanding Enable evolutionary development 4/2/2012 (C) USC-CSSE

22 Problems When implementation and design are different
The only way to understand implementation is to read through code Documented artifacts appear useless Wasted efforts and time Ultimately, Lose-Lose situation Unhappy clients Unhappy developers bugged by clients Unhappy maintainers 4/2/2012 (C) USC-CSSE

23 Architectural Drift Classic problem in software engineering and software maintenance Often happen slowly during implementation Developers feel changes are minor Effects of changes multiply 4/2/2012 (C) USC-CSSE

24 Requirements-to-Code Elaboration
Impact factor from one step to the next Increase in number of “statements” Clearly, significant impact when changes made to early stages Objective x 2.46 Shall Statements x 0.89 Use-Case x 7.06 Use-Case Steps x 66.91 SLOC * Ali Afzal Malik, Supannika Koolmanojwong, Barry Boehm. “An Empirical Study of Requirements-to-Code Elaboration Factors 4/2/2012 (C) USC-CSSE

25 Faithful Implementation
The definition Structural elements  Source code All should be there Source code must not utilize new major computational elements not specified in architecture Source code must not contain new connections not found in architecture Can we deviate from this? 4/2/2012 (C) USC-CSSE

26 Unfaithful Implementation
The implementation has its own architecture Implementation is the architecture Impacts of failure to recognize distinction between designed and implemented architecture Ability to reason about application’s architecture in future Misleading (what they think vs. what they have) Evolution strategies based on documented architecture doomed to failure 4/2/2012 (C) USC-CSSE

27 Two-Way Mapping This is what should have been done
Changes can be discovered during design or implementation phases What to do? How to effectively handle? 4/2/2012 (C) USC-CSSE

28 Design to Implementation
Decide to first visit the design Update the design Review the changes Implement according to the new design Always have a “blue print” to refer to Architects may have more understanding on impact of design changes Easier to foresee future impacts 4/2/2012 (C) USC-CSSE

29 Implementation to Design
Changes made to the implementation immediately Then trace back to design Update design to reflect new implementation Easier from developers perspective Many changes may have been missed in design update Difficult to foresee future effects Unless highly experienced 4/2/2012 (C) USC-CSSE

30 Preparation Source code files SSAD and UML models Personnel
As implemented SSAD and UML models Personnel Must be present: Developer (coder) Architect(s) Optional Other team members 4/2/2012 (C) USC-CSSE

31 Review Process Mainly done with code tracing and walkthrough
Design patterns / Architecture frameworks Which is specified in SSAD? Meet the standards? Design classes vs. Implemented classes Consistent attributes Consistent operations Use-case tracing Consistency between use-case behavior and implementation 4/2/2012 (C) USC-CSSE

32 Grading Guidelines Total = 15 points
(3) Faithfulness to design patterns / architecture frameworks (5) Faithfulness in design classes to implemented classes mapping (5) Accuracy of implemented Use-Case behaviors (2) Overall 4/2/2012 (C) USC-CSSE

33 CS 577b Software Engineering II -- Introduction
1 April 2017 Milestone Reviews Rebaselined Development Commitment Review Design Code Review Core Capability Drive thru Transition Readiness Review © USC Center for Software Engineering

34 Core Capabilities Drive-thru
©USC-CSSE

35 ©USC-CSSE

36 CCD vs Testing ©USC-CSSE

37 CCD Purpose Improve likelihood of successful transition
Improve operational stakeholder communication & motivation Sense of what they’ll be getting Hands-on usage opportunity Product will soon be theirs to manage Determine whether developers are on right track Use real operational scenarios (preferred) ©USC-CSSE

38 CCD Purpose Determine whether client needs anything further to ensure successful Transition and Operation Changes in priorities for remaining features? Changes being made to operational procedures? More materials needed for training? Changes in system data or environment? Anyone else who should experience CCD? ©USC-CSSE

39 Collaboration Problem
Exploration & Valuation Foundations Development Operations Construction Transition ©USC-CSSE

40 Exploration & Valuation
Solution: CCD Exploration & Valuation Foundations Development Operations Construction Transition ©USC-CSSE

41 Developer Preparation
Schedule drive–through time with client 40-60 minutes generally OK Place: SAL 322, SAL 329 Discuss with client Agenda Core Capabilities Scenarios (acceptance test sub-set) Drive–through users Coordinate with 577b staff schedule prior to CCD Specify hardware/software required (if needed) ©USC-CSSE

42 Developer Preparation
Acceptance Test Subsets Prepare draft User’s Manual Bring hard copies for clients & others Minimally: describe how to use core capabilities Outline form 1 high-level per capability Sublevels describe steps to perform capability Index cards 1-2 cards per capability Steps to perform capability on cards ©USC-CSSE

43 Developer Preparation
Prepare & dry run context presentation Bring hard copies for clients & others Concern Logs Can be in any form 577 template OR Your own Included in the report ©USC-CSSE

44 Client Preparation Communicate with client
Not just limited to client(s), but user(s) as well Plan “user” test scenario(s) of core capabilities High-level description of typical usage Should exercise capabilities in way user would May want to discuss with Intended users Acceptance Test developers Data, usage scenarios, users, etc. ©USC-CSSE

45 CCD : Baseline Agenda Summary of Core Capability content
Prioritized capabilities Review example Core Capability usage scenario Hands-on client usage Most of time should be spent here Discussion of IOC priorities Tailor agenda to your project ©USC-CSSE

46 Client’s “Hands-on” Usage
Imagine the reality once software is delivered Let the clients play with the system Use of user’s guide/manual DO NOT tell the clients what to do Observe and listen Usability Reactions Etc. ©USC-CSSE

47 CCD Products Concern logs (include things customer liked)
Core capabilities User’s Manual Tutorial Test Cases As appropriate Re–prioritized list of remaining features List of changes Operational procedures System data or environment developers ©USC-CSSE

48 CCD Report Gather and submit As-Is user’s manual Concern Logs
Record of demonstration as performed Summarize Core Capabilities driven–through Include suggestions and positive feedbacks Be specific Break down by capability New risks, if any, and mitigation plans Things that are Core Capabilities, but were NOT exercised: Mitigation = repeat CCD? Core capabilities not ready: Mitigation = do afterwards, coordinated with Client Changes in understanding Reprioritized capabilities, if any COCOMO Estimation + Code Count reports ©USC-CSSE

49 CCD Motivation Effort for remaining work More data for analysis
Past estimation Overestimate? Underestimate? Analyze past estimations ©USC-CSSE

50 CCD Summary CCD is an opportunity to Set customer expectations
Get positive feedbacks and suggestions Validate core capabilities Validate development directions and understandings Ease transition Identify new risks and mitigations ©USC-CSSE

51 Grading Guidelines Total = 15 points (3) Preparation for the CCD
(5) Progress of your work (7) Quality of the core capabilities 4/2/2012 (C) USC-CSSE

52 CS 577b Software Engineering II -- Introduction
1 April 2017 Milestone Reviews Rebaselined Development Commitment Review Design Code Review Core Capability Drive thru Transition Readiness Review © USC Center for Software Engineering

53 CSCI 577b Software Engineering II, TRR Preparation
4/1/2017 TRR Package Overview Transition Set Transition plan User manual Support Set Support plan Training materials inc. Tutorials & sample data Test plan, cases, and results ©USC-CSSE © USC-CSE

54 CSCI 577b Software Engineering II, TRR Preparation
4/1/2017 Transition Plan “Ensure that system’s operational stakeholders are able to successfully operate & maintain system” Plans for change from development mode to operational mode Site installation & test Load data Pilot Operations Preparations for roll-out ©USC-CSSE © USC-CSE

55 CSCI 577b Software Engineering II, TRR Preparation
4/1/2017 User Manual Teach & guide user on how to use product i.e., describe Steps For running SW Performing operations Expected Inputs Output(s) Measures to be taken if errors occur ©USC-CSSE © USC-CSE

56 CSCI 577b Software Engineering II, TRR Preparation
4/1/2017 Support Plan Guide system’s support stakeholders (administrators, operators, maintainers, …) on successful Operation Maintenance [and Enhancement?] ©USC-CSSE © USC-CSE

57 CSCI 577b Software Engineering II, TRR Preparation
4/1/2017 Training Materials Identify training Objectives Schedule Participants Prepare Lectures Examples Exercises Prepare any sample data need for training ©USC-CSSE © USC-CSE

58 TRR Presentation Summary
CSCI 577b Software Engineering II, TRR Preparation 4/1/2017 TRR Presentation Summary Specific requirements for your presentation: Your product! i.e., fully working IOC version Salesman-like discussion of your project’s usefulness Base on your business case, etc Why is system going to be really great for customer Transition issues & transition plan if you delivered your product how did it go? (you should have by presentation) If not, when? Support issues How will you support product, once deployed? E.g. next term, for instance OK to say that You will never touch it ever again Everything’s up to customer  ©USC-CSSE © USC-CSE

59 CSCI 577b Software Engineering II, TRR Preparation
4/1/2017 TRR Agenda (80 Minutes) 10 min. Introduction Operational concept overview, TRR specific outline, transition objective & strategy 25 min. Demo of IOC (Product status demonstration) 5 min. Support Plan 10 min. Data Reporting & Archiving (if any) 15 min. Summary of Transition Plan (as appropriate) HW, SW, site, staff preparation Operational testing, training, & evaluation Stakeholder roles & responsibilities Milestone plan Required resources Software product elements (code, documentation, etc.) 15 min. Feedback *** Times are approximate *** ©USC-CSSE © USC-CSE

60 Grading Guidelines Total = 50 points (20) Progress of your work
(10) Presentation (5) Risk Management (15) Quality 4/2/2012 (C) USC-CSSE

61 Other things about milestone reviews
Phase shifting The milestones are being made, but the work hasn’t actually been completed, hence shifting it to subsequent phase Project signoff / Project close-out Signifies completeness or business acceptance of the deliverable Prepare list of deliverables in advance Phase signoff – check point Conditional signoff – specific conditions that will need to be met in the succeeding phases; spike in Scrum; need more feasibility evidence Acceptable variance signoff – not completely satisfy, but deliver with acceptable variance Postponed signoffs – move to next checkpoint, should not happen Closeout – sometimes include lesson learned , post-implementation report, recognize outstanding work, archive project records Ref: ©USC-CSSE

62 Outline Schedule Marks Allocation Possible 577b risks
Guest Lecturers TechTalk Pair Research Presentation Marks Allocation Possible 577b risks Team Re-Formation (C)USC-CSSE

63 Potential Guest Lecturers
Boeing Defense Acquisition University WSR Consulting Group, LLC JPL Vresorts, Inc. (C)USC-CSSE

64 TechTalk 7 minutes in-class presentation
predefined topics PM tools, QA & Testing tools, Dev tools & frameworks Don’t pick a topic that you already know pick a new one, challenging one Mainly open source tools some commercial for free 10days/30days Imagine your manager ask you to review the tool/technology Use the tool, try the technology Report it to the class good points, bad points, when to use it, should we use it (C)USC-CSSE

65 TechTalk Schedule Date Topics Activities 2/5/2014 System Acquisition
TechTalk I 2/12/2014 Rebaselined DCR ARB 2/19/2014 Requirements Volatility TechTalk II 2/26/2014 Software Maintenance TechTalk III 3/5/2014 Design-Code Review 3/12/2014 Software Engineering standards TechTalk IV 3/19/2014 Spring Break 3/26/2014 Core Capability Drivethrough 4/2/2014 12 Knowledge Areas Every USC IT Engineering Student Should Know! TechTalk V (C)USC-CSSE

66 DEN/ Remote students Call in Presentation in person [optional]
Presentation through webex Presentation in person [optional]

67 TechTalk Process W Jan 15 Topics and schedule posted on doodle Pick the topic and schedule that you are interested in Prepare your presentation T Jan 28 Last day of selecting and scheduling TechTalk W Feb 5 First TechTalk Note: If you have an interesting tool / framework that is not in the list, please let me know before Jan 22. Doodle link: (C)USC-CSSE

68 TechTalk 45 points 10 points: Presentation preparation and delivery
30 points: Content 5 points: Time Management (C)USC-CSSE

69 TechTalk Topics - I Presentation date: February 5, 2014 PM tools 1
TuLeap - Life Cycle Management Software - 2 Alfresco - open source content management platform - 3 SugarCRM - 4 Feng Office - Project Management tool - 5 Activiti - BPM Tool - 6 Bonita BPM 6 - BPM tool - 7 ProjectLibre - Project Management Tool - 8 LibrePlan - Project Management Tool - 9 OpenProject - Project Management Tool - https://www.openproject.org/ 10 RedMine - Project Management Tool - (C)USC-CSSE

70 TechTalk Topics - II Presentation date: February 19, 2014
QA &Testing tools 1 Badboy Software (www.badboy.com.au), web automated testing tool 2 Selenium (automated testing tool) - SElinium IDE (Beginner) 3 Selenium (automated testing tool) - SElinium WebDriver (Advanced) 4 Geb (browser automation solution) - 5 Cucumber - BDD tool - 6 Lettuce - BDD tool - 7 Robot Framework - test automation framework - 8 Jmeter 9 Tsung - Load Testing Tool - 10 Load Impact - Performance Testing Service on the cloud - (C)USC-CSSE

71 TechTalk Topics - III Presentation date: February 26, 2014
QA &Testing tools 11 Phabricator - Peer Code Review Tools - 12 Capybara - Web app testing tool - 13 Tarantula - Testing tool - 14 Smartbear - Testing tool - 15 Load Runner - performance testing tool - 16 QuickTest Professional HP - Functional Testing - 17 Crubible - Collaborative peer code review - https://www.atlassian.com/software/crucible/overview 18 IBM AppScan - Security Testing Tool Development framework HTML 5 (C)USC-CSSE

72 TechTalk Topics - IV Presentation date: March 12, 2014
QA &Testing tools 19 AppPerfect Load Test - 20 AppPerfect Web Test - 21 AppPerfect App Test - 22 AppPerfect Java Code Test - 23 AppPerfect Java Unit Test - Development tools and frameworks 1 Django - opensource web application framework 2 MongoDB - NoSQL DB 3 Couchbase Server - NoSQL DB - 4 Apache Hadoop - 5 Apache Sqoop - (C)USC-CSSE

73 TechTalk Topics - V Presentation date: April 2, 2014
Development tools and frameworks 7 Bootstrap - 8 Less - 9 AngularJS - 10 Backbone.js - 11 D3 - Data Driven Documents - 12 Jenkins - 13 Rasberry Pi - 14 Apache Shiro - Java Security Framework - 15 Varnish - Web application accelerator - https://www.varnish-cache.org/ 16 Docker - Cloud application development tool - (C)USC-CSSE

74 Outline Schedule Marks Allocation Possible 577b risks
Guest Lecturers TechTalk Pair Research Presentation Marks Allocation Possible 577b risks Team Re-Formation (C)USC-CSSE

75 Individual Research Presentation
Not report, not inform Presentation PPT, vdo, demo, prototype 10 minutes presentation 2 minutes Q & A Peer review as in-class quizzes

76 Possible topics Any software/ systems engineering topics
Not limited to process improvement BUT needs to relate to CSCI577ab Or at least provide benefits to the class Or use CSCI577ab knowledge to apply to your topic

77 Possible Topics Green and sustainable software
Cooperative and Human Aspects of Software Engineering Games and Software Engineering Software Engineering for Secure Systems Software Engineering for Cloud Computing Product Line Approaches in Software Engineering Managing Technical Debt Software Clones Automation of Software Test Software Measurements Developing Tools as Plug-ins Software Processes

78 Possible Topics - Software processes
Agile/Lean processes in software and systems development Assessment and improvement of software and systems processes Cost estimation and project planning Global software and systems development Software and systems supply chain Life cycle development methods including product-line engineering and all others Modeling and simulation of software and systems processes Novel techniques for process representation and analysis of software and systems processes Process improvement Process tools and metrics for software and systems engineering Studies focused on specific portions of the development lifecycle including requirements engineering, design, testing, independent verification and validation and others Process issues in health care, transportation, and automation systems

79 Not so good topics The Rational Unified Process
What is Cloud Computing? Model-View-Controller Architecture

80 DEN/ Remote students Call in Presentation in person [optional]
Presentation through webex Presentation in person [optional]

81 A guide to presenters 10 minutes presentation
[accepted] HW-2 Submit Research Proposal March 12 Acceptance Notification April 2 Announce Presentation Date April 9 Presentation April 23, May 30 [not accepted] 10 minutes presentation Submit your presentation 24 hours before your presentation schedule

82 Research proposal (HW2)
Due: March 12 15 points Abstract words Keywords References

83 Marks allocation Research Proposal – 15 points
Presentation – 45 points 5 points : Interesting 5 points : Soundness 5 points : Contribution to 577 5 points : Benefit to SE students 5 points : Collaboration 10 points : Quality of Work 10 points : Quality of Presentation

84 Examples of research presentation from previous years
Business Case Analysis and Tool for Software Engineering Course – Kantipa Lumyai (xls) A Case Study of Web Interface Design Patterns - Mark Villanueva Video Game Development and Incremental Commitment - Stephen Rice Green Software Engineering – Sheryl John (C)USC-CSSE

85 Outline Schedule Marks Allocation Possible 577b risks
Guest Lecturers TechTalk Pair Research Presentation Marks Allocation Possible 577b risks Team Re-Formation (C)USC-CSSE

86 Marks Allocation Category % Individual Score (HW/In-Class) 23%
Individual Critique 11% Tech Talk & Pair Research Presentation Individual Contribution 5% Team Score 45% Client Evaluation 100% (C)USC-CSSE

87 CS 577b Software Engineering II -- Introduction
1 April 2017 Primary CS577b Risk Items Personnel Commitment Compatibility Ease of communication Skills (management, web/java, Perl, CGI, data compression, …) Schedule Project scope IOC content Critical-path items (COTS, platforms, reviews, …) COTS See next chart Multiple COTS (C)USC-CSSE © USC Center for Software Engineering

88 Primary CS577b Risk Items (cont.)
CS 577b Software Engineering II -- Introduction 1 April 2017 Primary CS577b Risk Items (cont.) Requirements & UI Not matching client user needs Performance Memory, Disk Space usage (#Bits) Bus, Network, CPU utilization & bandwidth (#Bits/sec) Overhead sources Reliability of deliver Safe Secure External tasks Client/operator preparation Commitment for transition (C)USC-CSSE © USC Center for Software Engineering

89 COTS & External Component Risks
CS 577b Software Engineering II -- Introduction 1 April 2017 COTS & External Component Risks COTS risks Immaturity Inexperience Incompatibility with Application Platform Other COTS Controllability (C)USC-CSSE © USC Center for Software Engineering

90 COTS & External Component Risks (cont.)
CS 577b Software Engineering II -- Introduction 1 April 2017 COTS & External Component Risks (cont.) Non-commercial off-the shelf components Sources Reuse libraries Government (GOTS) Universities (ROTS) Issues Qualification testing Benchmarking Inspections Reference checking Compatibility analysis Both Safety Dependability Security (C)USC-CSSE © USC Center for Software Engineering

91 Top 11 - Risk distribution in CSCI577
(C)USC-CSSE

92 Comparing between risks in Fall and Spring
(C)USC-CSSE

93 Heads-Up: CS 577b Planning Common LCP Problems @ RDCR
CS 577b Software Engineering II -- Introduction 1 April 2017 Heads-Up: CS 577b Planning Common LCP RDCR RDCR operational prototype, business-case iterations: What have you done since last semester? Too many internal-increment deliverables Lack of core-capability specifics End-to-end demonstrable capability Lack of specific team member responsibilities By artifact & increment; but flexible Transition preparation Transition-leader’s success plan (teammates, clients) (C)USC-CSSE © USC Center for Software Engineering

94 CS577 Academic Integrity Guidelines
CS 577b Software Engineering II -- Introduction 1 April 2017 CS577 Academic Integrity Guidelines Individual Assignments OK to discuss Not OK to copy each others’ solution elements Not OK to copy external sources without attribution Within “Fair Use Guidelines” Team Assignments OK to use other teams’ patterns e.g. MS Project tasks Must give credit!!! Not OK to copy other teams’ complete/partial solutions e.g. MS course & project schedules (C)USC-CSSE © USC Center for Software Engineering

95 Outline Overview Schedule Marks Allocation Possible 577b risks
In-Class Team Discussion Guest Lecturers Individual Research Presentation Marks Allocation Possible 577b risks Team Re-Formation (C)USC-CSSE

96 577b project roles Project Manager Implementer Tester Trainer IIV&Ver
Quality Focal Point (C)USC-CSSE

97 (C)USC-CSSE

98 577b Project Activities Rebaselined Foundations Phase
(C)USC-CSSE

99 577b Project Activities Development Phase – Construction Increment
(C)USC-CSSE

100 577b Project Activities Development Phase – Transition Increment
(C)USC-CSSE

101 577b Project Artifacts Exploration, Valuation, and Foundations set
OCD, SSAD, LCP, FED Initial Operational Capability set Test Plan & Cases, Test Procedures & Results Iteration Plan & Iteration Assessment Report (part of LCP) CCD Report Transition and Support set Transition Plan, Training Materials Regression Test Package User Manual (C)USC-CSSE

102 Team Reformation Project On-Campus Off-campus Note 1
LA Commons Upgrade of Website ?? 2 City of Los Angeles Personnel Department 5 3 Mission Science 1-sem 4 LiveRiot – social networking enhancement e-Lockbox 6 Yanomamo Interactive DVD/online 7 ThrdPlace Social Networking 8 LOSE4GOOD.org 9 City of Los Angeles Public Safety 10 Student Scheduling System Part II 11 Surgery Assist 12 Online wedding invitations 13 Spherical Modeling Tool 14 Healthy Kids Zone 15 JEP Online Platform 16 MedFRS Available : Hasan Ali H Al Yousuf Abdulkareem Vindhya Awari Tu Duoung Ari Summer T01-Huaiqi Wang T09-Shreyas Devaraj (C)USC-CSSE


Download ppt "CS 577b: Software Engineering II"

Similar presentations


Ads by Google