Cs 577a fcr feedback fall 2009
1 / 20

CS 577a FCR Feedback, Fall 2009 - PowerPoint PPT Presentation

  • Uploaded on

CS 577a FCR Feedback, Fall 2009. Winsor Brown, Barry Boehm, Supannika Koolmanojwong October 30, 2009. 1. ARB Review Success Criteria. FCR For at least one architecture , a system built to that architecture will: Support the Ops Concept Satisfy the Requirements

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'CS 577a FCR Feedback, Fall 2009' - carr

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Cs 577a fcr feedback fall 2009

CS 577a FCR Feedback, Fall 2009

Winsor Brown, Barry Boehm,

Supannika Koolmanojwong

October 30, 2009


Arb review success criteria
ARB Review Success Criteria

  • FCR

  • For at least one architecture, a system built to that architecture 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)

  • DCR

  • For the selected architecture, a system built to the architecture 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


Overall fcr feedback
Overall FCR Feedback

  • Generally done well: presentations, client rapport

  • Reconcile FCR content with ARB Success Criteria

  • Define ALL key terms, acronyms in SID-glossary

  • If you’re deferring or skipping a normally-included artifact, explain why (e.g. COTS internals unavailable) and note in SID-document tailoring section.

  • Occassional order changes without telling us in a modified agenda

  • Role of primary DEN/remote student often mis-stated

    • IS System/Project Engineer (S/PE)

    • Includes IIV&V (also done by second DEN/remote student)

    • Includes Shaping (and re-shaping throughout semesters)


Overall fcr feedback 2
Overall FCR Feedback - 2

  • When asked a question:

    • Give the answer in brief, this will help you in time management and the Review Board will get the desired information

    • Do NOT answer back while Review Board attempts to provide guidance

  • Many had poor time management; indicated that presentation(s) had NOT been practiced

  • Occassional pointing at laptop screen, not projected image

  • Very occassionally, slides with NO value added

  • At least one team used "template" from 577a 2008: implies an unethical process


Ocd feedback 1
OCD Feedback (1)

  • Generally done well: Organizational goals, Operational concept, System boundary and organizational environment.

  • Some benefits chains need rework:

    • Added stakeholders: users, clients, developers, IIV&Vers, database administrators, maintainers, interoperators, suppliers

    • Assumptions are about environment not about outcome

    • Involvement/use of system before system is built

  • System boundary diagram

    • If you are using the component in/for your system, remove it from environment, e.g. PHP, .NET framework.


Ocd feedback 2
OCD Feedback (2)

  • Organization Goals

    • Are Benefits Chain End Outcomes,

    • NOT project Initiative contributions

  • Identify Levels of Service properly

    • 100% availability, 100% reliability - not feasible!

    • Make sure you can measure LOS goals

  • Prototypes and System are NOT the same (usually)

  • Business Workflow

    • Use activity-type diagram

    • Illustrate business activities

      • Not technical/system activity

      • May not even “see” system explicitly u


Current business workflow example from 2008
Current BusinessWorkflowExample from 2008

Prototype feedback
Prototype Feedback

  • Generally done well: GUI Prototypes, Good understanding of client’s needs

  • Prototype all high-risk elements, not just GUI’s

    • COTS interoperability, performance, scalability

  • Use user/client-friendly terms

    • “John Doe, 22 Elm St.” not abstractions “Name1, Addr1”

    • Use as an opportunity to gather more information and/or examples

  • Identify end users and try to get feedback from end users

  • Focus on important and high priority requirements (initially)


Ssrd feedback
SSRD Feedback

  • Generally done well: Project and Capability requirements, OCD-SSRD traceability

  • Prioritize all the requirements

  • Propagate LOS goals from OCD into SSRD or drop LOS requirements from SSRD (and SSAD)

  • Distinguish between client imposed requirements (SSRD) and developer choice solution (SSAD)

  • Make sure all requirements are testable

  • Qualify “24/7” Availability with noted exceptions

  • Update the new requirements in WikiWinWin tool

  • There is no such thing as an “implicit requirement”


No-SSRD Feedback

  • Result of a good after class question by a team doing NDI/NCS intensive but who found SSRD contents useful.

    • Why not requested? Because you can't impose "requirements" on COTS or NCS; alternatively, COTS/NCS capability become the requirements

    • Next year we will have NDI/NCS submit WinWin Report as part of packages

    • This year: put information in SID; they are needed for Test Case Development.

Ssad feedback
SSAD Feedback

  • Generally done well: Overall views

  • Follow UML conventions (arrows, annotations, etc.)

  • Generalization of actors

  • Uncommon mistakes in use-case diagrams

    • Two actors-one use case (means BOTH present)

    • Arrow direction for <extends> or <includes>

  • Devil is in the detail; simple is the best

  • Only two teams (3 and 14) had an adequate start on Information & Arctifacts Diagram

  • Read the exit criteria for the milestone carefully


Lcp feedback 1
LCP Feedback - 1

  • Generally done well: overall strategy, roles and responsibilities

  • Fill in 577b TBDs

  • Identify required skills for NN new team member(s) (577b; if needed to meet "team size")

  • Show (concentrate on) your future plan; not the past

  • Full Foundations [nee Elaboration] phase plan

  • Don’t plan ONLY for documentation

    • Include Modeling

    • Include Prototyping; coding; executable architecture


Lcp feedback 2
LCP Feedback - 2

  • COCOMO drivers

    • Usually differ per the module

    • PMATs rationale was often wrong:

      • CS577 projects' process maturity is between 2 and 3

      • NOBODY did the detailed check list in the SwCEwCII book!

    • Some driver rationales were "ridiculous"

  • Add DEN Student interactions to the Gantt Chart

    • IIV&V

    • System/Project Engineer (includes Shaping)

  • Add maintainer’s responsibilities


Fed feedback
FED Feedback

  • Generally done well: Business case framework, risk analysis

  • Specify LOS feasibility plans

  • Include training, operations, maintenance, opportunity costs/effort

  • Few had developers hours as cost

  • Try to quantify benefits, show return on investment

  • Change ROI to reflect on-going costs (possibly savings)

  • Distinguish one-time from annual costs in business case

  • Benefits start in mid 2010 (go to 6 month granularity);Costs start mid 2009

  • Elaborate process rationale

  • Complete section 6 – COTS Analysis


Sid feedback
SID Feedback

  • Requirements traceability

    • OC  WinC  SSRD  SSAD

    • Update every time there is a change

  • Update Glossary!

  • Glossary MUST have all system/project specific terms

    • Non-standard (unusual uses)



  • Generally done well

  • Some missing traceability injection-removal matrix

  • Some seemed to try to snow us with data, not present just a quick summary

  • Did NOT specify type of "Peer Review"

    • Pass around or Buddy Check (NOT desirable: no record of concerns)

    • Agile Artifact Review

    • Agile Internal/Informal (Role Based) Peer Review

  • Will have lots more to say at DCR!


Remote students system project engineer iiv v shaping
Remote Students: System/Project Engineer (IIV&V & Shaping)

  • Generally done well

  • Constructive comments-how to improve

  • Some Shapers did not follow instructions:

    • No WinC summary (mostly numbers)[I am expecting update by email for those told]

    • Other parts incomplete or mis-understood


Things to improve
Things to improve

  • Presentation – communication skill

    • One word wrong could lead to billion $ loss.

  • Practice in front of others

  • Be concise and precise

  • Consistencies among each artifact

  • Team work vs. integrated individual works

  • Prepare your client:

    • Tell them what an ARB is (use agenda, success criteria)

    • Tell them what to expect from ARB

  • Time management

    • Get in and set-up ASAP

    • Have documents & client present