Presentation is loading. Please wait.

Presentation is loading. Please wait.

University of Southern California Center for Systems and Software Engineering CS 577b: Software Engineering II Class Introduction.

Similar presentations


Presentation on theme: "University of Southern California Center for Systems and Software Engineering CS 577b: Software Engineering II Class Introduction."— Presentation transcript:

1 University of Southern California Center for Systems and Software Engineering CS 577b: Software Engineering II Class Introduction

2 University of Southern California Center for Systems and Software Engineering Outline Schedule –Guest Lecturers –TechTalk –Pair Research Presentation Marks Allocation Possible 577b risks Team Re-Formation (C)USC-CSSE2

3 University of Southern California Center for Systems and Software Engineering Course Schedule See –http://greenbay.usc.edu/csci577/spring2014http://greenbay.usc.edu/csci577/spring2014 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-CSSE3

4 University of Southern California Center for Systems and Software Engineering Milestone Reviews Rebaselined Development Commitment Review Design Code Review Core Capability Drive thru Transition Readiness Review

5 University of Southern California Center for Systems and Software Engineering Milestone review ©USC-CSSE5

6 University of Southern California Center for Systems and Software Engineering The Incremental Commitment Spiral Model 6©USC-CSSE

7 University of Southern California Center for Systems and Software Engineering (C)USC-CSSE7 ICSM –Class Milestones 2/12 3/26 4/164/30 3/5 Code Review

8 University of Southern California Center for Systems and Software Engineering (C)USC-CSSE8

9 University of Southern California Center for Systems and Software Engineering University of Southern California Center for Systems and Software Engineering 9 4 ARB Review Success Criteria FCRDCR 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: Support the Ops Concept Satisfy the Requirements Be faithful to the Prototype Be buildable within the budgets and schedules in the Plan All major risks resolved or covered by risk management plan Key stakeholders committed to support full life cycle

10 University of Southern California Center for Systems and Software Engineering Commitment Review Success Criteria 10 TRR / OCR 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 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? CCD

11 University of Southern California Center for Systems and Software Engineering University of Southern California Center for Systems and Software Engineering 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

12 University of Southern California Center for Systems and Software Engineering 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 12

13 University of Southern California Center for Systems and Software Engineering University of Southern California Center for Systems and Software Engineering 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 University of Southern California Center for Systems and Software Engineering University of Southern California Center for Systems and Software Engineering 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.

15 University of Southern California Center for Systems and Software Engineering Grading Guidelines Total = 50 points (20) Progress of your work (10) Presentation (5) Risk Management (15) Quality 4/2/201215(C) USC-CSSE

16 University of Southern California Center for Systems and Software Engineering 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-CSSE16

17 University of Southern California Center for Systems and Software Engineering Milestone Reviews Rebaselined Development Commitment Review Design Code Review Core Capability Drive thru Transition Readiness Review

18 University of Southern California Center for Systems and Software Engineering ©USC-CSSE18

19 University of Southern California Center for Systems and Software Engineering Internal Code Review 19©USC-CSSE

20 University of Southern California Center for Systems and Software Engineering Outline Problems & Motivation Faithful vs. Unfaithful Preparation and Review Process 4/2/201220(C) USC-CSSE

21 University of Southern California Center for Systems and Software Engineering 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/201221(C) USC-CSSE

22 University of Southern California Center for Systems and Software Engineering 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/201222(C) USC-CSSE

23 University of Southern California Center for Systems and Software Engineering 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/201223(C) USC-CSSE

24 University of Southern California Center for Systems and Software Engineering Requirements-to-Code Elaboration Impact factor from one step to the next Increase in number ofstatements Clearly, significant impact when changes made to early stages Objective Shall Statements Use-Case Use-Case Steps SLOC x 2.46 x 0.89 x 7.06 x * Ali Afzal Malik, Supannika Koolmanojwong, Barry Boehm. An Empirical Study of Requirements-to-Code Elaboration Factors 4/2/201224(C) USC-CSSE

25 University of Southern California Center for Systems and Software Engineering 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-CSSE25

26 University of Southern California Center for Systems and Software Engineering 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 applications 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-CSSE26

27 University of Southern California Center for Systems and Software Engineering 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/201227(C) USC-CSSE

28 University of Southern California Center for Systems and Software Engineering 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/201228(C) USC-CSSE

29 University of Southern California Center for Systems and Software Engineering 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/201229(C) USC-CSSE

30 University of Southern California Center for Systems and Software Engineering Preparation Source code files –As implemented SSAD and UML models Personnel –Must be present: Developer (coder) Architect(s) –Optional Other team members 4/2/201230(C) USC-CSSE

31 University of Southern California Center for Systems and Software Engineering 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/201231(C) USC-CSSE

32 University of Southern California Center for Systems and Software Engineering 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/201232(C) USC-CSSE

33 University of Southern California Center for Systems and Software Engineering Milestone Reviews Rebaselined Development Commitment Review Design Code Review Core Capability Drive thru Transition Readiness Review

34 University of Southern California Center for Systems and Software Engineering Core Capabilities Drive-thru ©USC-CSSE34

35 University of Southern California Center for Systems and Software Engineering ©USC-CSSE35

36 University of Southern California Center for Systems and Software Engineering CCD vs Testing ©USC-CSSE36

37 University of Southern California Center for Systems and Software Engineering CCD Purpose Improve likelihood of successful transition Improve operational stakeholder communication & motivation –Sense of what theyll 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-CSSE37

38 University of Southern California Center for Systems and Software Engineering 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 38

39 University of Southern California Center for Systems and Software Engineering Collaboration Problem ©USC-CSSE 39 Exploration & Valuation Foundations Development Operations ConstructionTransition

40 University of Southern California Center for Systems and Software Engineering Solution: CCD ©USC-CSSE 40 Exploration & Valuation Foundations Development Operations ConstructionTransition

41 University of Southern California Center for Systems and Software Engineering Developer Preparation ©USC-CSSE 41 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)

42 University of Southern California Center for Systems and Software Engineering Developer Preparation ©USC-CSSE 42 Acceptance Test Subsets Prepare draft Users 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

43 University of Southern California Center for Systems and Software Engineering Developer Preparation ©USC-CSSE 43 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

44 University of Southern California Center for Systems and Software Engineering Client Preparation ©USC-CSSE 44 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.

45 University of Southern California Center for Systems and Software Engineering CCD : Baseline Agenda ©USC-CSSE 45 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

46 University of Southern California Center for Systems and Software Engineering Clients Hands-on Usage ©USC-CSSE 46 Imagine the reality once software is delivered Let the clients play with the system Use of users guide/manual –DO NOT tell the clients what to do Observe and listen –Usability –Reactions –Etc.

47 University of Southern California Center for Systems and Software Engineering CCD Products ©USC-CSSE 47 Concern logs (include things customer liked) –Core capabilities –Users Manual –Tutorial –Test Cases As appropriate –Re–prioritized list of remaining features –List of changes Operational procedures System data or environment developers

48 University of Southern California Center for Systems and Software Engineering CCD Report ©USC-CSSE 48 Gather and submit –As-Is users 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

49 University of Southern California Center for Systems and Software Engineering CCD Motivation Effort for remaining work More data for analysis Past estimation –Overestimate? –Underestimate? Analyze past estimations 49©USC-CSSE

50 University of Southern California Center for Systems and Software Engineering CCD Summary ©USC-CSSE 50 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

51 University of Southern California Center for Systems and Software Engineering Grading Guidelines Total = 15 points (3) Preparation for the CCD (5) Progress of your work (7) Quality of the core capabilities 4/2/201251(C) USC-CSSE

52 University of Southern California Center for Systems and Software Engineering Milestone Reviews Rebaselined Development Commitment Review Design Code Review Core Capability Drive thru Transition Readiness Review

53 University of Southern California Center for Systems and Software Engineering 53 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

54 University of Southern California Center for Systems and Software Engineering 54 Transition Plan Ensure that systems 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

55 University of Southern California Center for Systems and Software Engineering 55 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

56 University of Southern California Center for Systems and Software Engineering 56 Support Plan Guide systems support stakeholders (administrators, operators, maintainers, …) on successful –Operation –Maintenance [and Enhancement?] ©USC-CSSE

57 University of Southern California Center for Systems and Software Engineering 57 Training Materials Identify training –Objectives –Schedule –Participants Prepare –Lectures –Examples –Exercises Prepare any sample data need for training ©USC-CSSE

58 University of Southern California Center for Systems and Software Engineering 58 TRR Presentation Summary Specific requirements for your presentation: –Your product! i.e., fully working IOC version –Salesman-like discussion of your projects 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 »Everythings up to customer ©USC-CSSE

59 University of Southern California Center for Systems and Software Engineering 59 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

60 University of Southern California Center for Systems and Software Engineering Grading Guidelines Total = 50 points (20) Progress of your work (10) Presentation (5) Risk Management (15) Quality 4/2/201260(C) USC-CSSE

61 University of Southern California Center for Systems and Software Engineering Other things about milestone reviews Phase shifting –The milestones are being made, but the work hasnt 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 ©USC-CSSE61 Ref:

62 University of Southern California Center for Systems and Software Engineering Outline Schedule –Guest Lecturers –TechTalk –Pair Research Presentation Marks Allocation Possible 577b risks Team Re-Formation (C)USC-CSSE62

63 University of Southern California Center for Systems and Software Engineering Potential Guest Lecturers Boeing Defense Acquisition University WSR Consulting Group, LLC JPL Vresorts, Inc. (C)USC-CSSE63

64 University of Southern California Center for Systems and Software Engineering TechTalk 7 minutes in-class presentation –predefined topics –PM tools, QA & Testing tools, Dev tools & frameworks Dont 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-CSSE64

65 University of Southern California Center for Systems and Software Engineering TechTalk Schedule DateTopicsActivities 2/5/2014System AcquisitionTechTalk I 2/12/2014Rebaselined DCR ARB 2/19/2014Requirements VolatilityTechTalk II 2/26/2014Software MaintenanceTechTalk III 3/5/2014Design-Code Review 3/12/2014Software Engineering standardsTechTalk IV 3/19/2014Spring Break 3/26/2014Core Capability Drivethrough 4/2/ Knowledge Areas Every USC IT Engineering Student Should Know!TechTalk V (C)USC-CSSE65

66 University of Southern California Center for Systems and Software Engineering DEN/ Remote students Call in –Presentation through webex Presentation in person [optional] 66

67 University of Southern California Center for Systems and Software Engineering 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 (C)USC-CSSE67 Note: If you have an interesting tool / framework that is not in the list, please let me know before Jan 22. Doodle link:

68 University of Southern California Center for Systems and Software Engineering TechTalk 45 points –10 points: Presentation preparation and delivery –30 points: Content – 5 points: Time Management (C)USC-CSSE68

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

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

71 University of Southern California Center for Systems and Software Engineering TechTalk Topics - III (C)USC-CSSE71 QA &Testing tools 11Phabricator - Peer Code Review Tools - 12Capybara - Web app testing tool - 13Tarantula - Testing tool - 14Smartbear - Testing tool - 15Load Runner - performance testing tool - solutions/software.html?compURI= QuickTest Professional HP - Functional Testing - 17Crubible - Collaborative peer code review - https://www.atlassian.com/software/crucible/overview https://www.atlassian.com/software/crucible/overview 18IBM AppScan - Security Testing Tool 03.ibm.com/software/products/en/appscan Development framework HTML 5 Presentation date: February 26, 2014

72 University of Southern California Center for Systems and Software Engineering TechTalk Topics - IV (C)USC-CSSE72 QA &Testing tools 19AppPerfect Load Test - 20AppPerfect Web Test - 21AppPerfect App Test - 22AppPerfect Java Code Test - test.html 23AppPerfect Java Unit Test - test.html Presentation date: March 12, 2014 Development tools and frameworks 1Django - opensource web application framework 2MongoDB - NoSQL DB 3Couchbase Server - NoSQL DB - 4Apache Hadoop - 5Apache Sqoop -

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

74 University of Southern California Center for Systems and Software Engineering Outline Schedule –Guest Lecturers –TechTalk –Pair Research Presentation Marks Allocation Possible 577b risks Team Re-Formation (C)USC-CSSE74

75 University of Southern California Center for Systems and Software Engineering Individual Research Presentation Research –Not report, not inform Presentation –PPT, vdo, demo, prototype 10 minutes presentation 2 minutes Q & A Peer review as in-class quizzes 75

76 University of Southern California Center for Systems and Software Engineering 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 76

77 University of Southern California Center for Systems and Software Engineering 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 77

78 University of Southern California Center for Systems and Software Engineering 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 78

79 University of Southern California Center for Systems and Software Engineering Not so good topics The Rational Unified Process What is Cloud Computing? Model-View-Controller Architecture 79

80 University of Southern California Center for Systems and Software Engineering DEN/ Remote students Call in –Presentation through webex Presentation in person [optional] 80

81 University of Southern California Center for Systems and Software Engineering A guide to presenters 10 minutes presentation Submit your presentation 24 hours before your presentation schedule 81 [not accepted] [accepted] HW-2 Submit Research Proposal March 12 Acceptance Notification April 2 Announce Presentation Date April 9 Presentation April 23, May 30

82 University of Southern California Center for Systems and Software Engineering Research proposal (HW2) Due: March points Abstract – words Keywords References 82

83 University of Southern California Center for Systems and Software Engineering 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 83

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

85 University of Southern California Center for Systems and Software Engineering Outline Schedule –Guest Lecturers –TechTalk –Pair Research Presentation Marks Allocation Possible 577b risks Team Re-Formation (C)USC-CSSE85

86 University of Southern California Center for Systems and Software Engineering Marks Allocation (C)USC-CSSE86 Category% Individual Score (HW/In-Class)23% Individual Critique11% Tech Talk & Pair Research Presentation11% Individual Contribution5% Team Score45% Client Evaluation5% 100%

87 University of Southern California Center for Systems and Software Engineering (C)USC-CSSE87 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

88 University of Southern California Center for Systems and Software Engineering (C)USC-CSSE88 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

89 University of Southern California Center for Systems and Software Engineering (C)USC-CSSE89 COTS & External Component Risks COTS risks –Immaturity –Inexperience –Incompatibility with Application Platform Other COTS –Controllability

90 University of Southern California Center for Systems and Software Engineering (C)USC-CSSE90 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

91 University of Southern California Center for Systems and Software Engineering Top 11 - Risk distribution in CSCI577 (C)USC-CSSE91

92 University of Southern California Center for Systems and Software Engineering Comparing between risks in Fall and Spring (C)USC-CSSE92

93 University of Southern California Center for Systems and Software Engineering (C)USC-CSSE93 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-leaders success plan (teammates, clients)

94 University of Southern California Center for Systems and Software Engineering (C)USC-CSSE94 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

95 University of Southern California Center for Systems and Software Engineering Outline Overview Schedule –In-Class Team Discussion –Guest Lecturers –Individual Research Presentation Marks Allocation Possible 577b risks Team Re-Formation (C)USC-CSSE95

96 University of Southern California Center for Systems and Software Engineering 577b project roles Project Manager Implementer Tester Trainer IIV&Ver Quality Focal Point (C)USC-CSSE96

97 University of Southern California Center for Systems and Software Engineering 97(C)USC-CSSE

98 University of Southern California Center for Systems and Software Engineering 577b Project Activities Rebaselined Foundations Phase (C)USC-CSSE98

99 University of Southern California Center for Systems and Software Engineering 577b Project Activities Development Phase – Construction Increment (C)USC-CSSE99

100 University of Southern California Center for Systems and Software Engineering 577b Project Activities Development Phase – Transition Increment (C)USC-CSSE100

101 University of Southern California Center for Systems and Software Engineering 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-CSSE101

102 University of Southern California Center for Systems and Software Engineering Team Reformation (C)USC-CSSE102 ProjectOn-CampusOff-campusNote 1LA Commons Upgrade of Website1?? 2City of Los Angeles Personnel Department51 3Mission Science1-sem 4LiveRiot – social networking enhancement1-sem 5e-Lockbox41 6Yanomamo Interactive DVD/online1-sem 7ThrdPlace Social Networking4 8LOSE4GOOD.org3 9City of Los Angeles Public Safety1?? 10Student Scheduling System Part II6 11Surgery Assist0 12Online wedding invitations1-sem 13Spherical Modeling Tool22 14Healthy Kids Zone61 15JEP Online Platform51 16MedFRS1-sem Available : -Hasan Ali H Al Yousuf -Abdulkareem -Vindhya Awari - Tu Duoung -Ari Summer -T01-Huaiqi Wang -T09-Shreyas Devaraj


Download ppt "University of Southern California Center for Systems and Software Engineering CS 577b: Software Engineering II Class Introduction."

Similar presentations


Ads by Google