phase 2 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Phase 2 PowerPoint Presentation

Phase 2

6 Vues Download Presentation
Télécharger la présentation

Phase 2

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Phase 2 Please go to the class web site and make sure your team link is accurate and functioning. Emails to me don't count.

  2. The essay

  3. Class participation & professionalism (individual) 10% The professional component includes not just the attendance, but emphasizes more pointedly the productive value of input a student offers to class discussion. It could also include professional behaviors such as not texting during class, looking at laptops when they are not needed for the class, and not talking with fellow students during class. It includes other aspects of professional behavior such as properly written emails, preparedness when attending office hours, and advanced notification for classes that are missed. I would add incentive, completeness, and level of effort when completing assignments

  4. Reasons to Get A Regrade

  5. Reasons to NOT Get A Regrade

  6. some trends • Double spaces, 2 in. margins, one-half page of total text • You should generally have more to say than that. • Definitive statements with no references / Internet quotes with no references • Grammar and spelling • Not following instructions - email to 3 people please • ONLY following instructions - no motivation to do more

  7. things that really counted • illustrations, pictures, links to more info. • research in not just your solution, but the background problem as well • exhaustive counter arguments • remember: • answering the requirements is a C • substantial understanding is a B • applying it to a wider audience and real life is an A • Contemporary & Important (5 pts) • contemporary but limited audience - 2-3 pts • applies to a non-engineering but limited population - 4 pts • widespread (at least city-wide) application - 5 pts

  8. Phase 3 • The Software Requirements Specification

  9. The Software Requirements Specification • After review of the customer’s System Spec. • After educated analysis • Preliminary design • A technical, software “approach” • Results in permission to detail-design and code

  10. Customer Points-of-Contention • Assumptions, Constraints, Limits • Function • Documentation – technical, user, and training manuals • Training • Maintenance / Enhancements • Requirements Changes • Status and Reviews

  11. From the customer’s perspective • How smart people are going to solve the problem that was stated in the System Spec. • A “contract”, more or less • Is it doable? • Technically • On time • Under budget

  12. Settles these issues: • Software Architecture • Object Oriented? • Structured? • Database Oriented (Informational Flow)? • Event Driven • Major Modules • to 2 or 3 levels of supervision • low level utilities if they touch hardware or the environment

  13. Risk Assessment • Technical Risks • hardware / software / interfaces • build vs. buy • team expertise needed • Schedule Risks • budget • calendar • personnel – level of expertise required

  14. Phase 3 • Write PARTS OF an SRS • Architectural Drawings • Main User Screen(s) • Integration Thread (also a Drawing) • Change of Scope Form • Cross Reference Listing

  15. What is a module? Storage Outputs Processing Inputs Simple Block Diagram Form Arrows, of course, should be labeled

  16. Data Flow Diagram Temporary Storage Sink Data Conversion Source DFD Standard Shapes Arrows, of course, should be labeled

  17. Air Traffic Control Radar Database Display Sweep Data Conversion Add Remove Edit Display Refresh UI Data Interpretation Disk Access Record Playback

  18. City Simulator

  19. Talking Head

  20. Talker

  21. Data Flow Diagram - shows movement, conversion, and storage of data This is the "top" drawing of a $6 million, 45-person, 1 million LOC, 4 year project

  22. Cloud Chart - (pre UML) object relationships

  23. VI. Change Request Form If you would like to make any changes to the project description, including new features, feature cuts, limitations, etc., please fill out this form send it to talkingheadcompanion@gmail.comas soon as possible. NOTE: Any change may impact the previously agreed-upon budget and schedule. Requestor Information Name:______________________________ Position:_______________________________ Phone: _____________________________ Email: _________________________________ Signature:______________________________________________ Date:_______________ Description of Modification Check one: [ ]Feature addition [ ]Feature Removal [ ]New Limitation [ ]Other:________________________ Module Affected:_____________________________________________________________ Description: Priority Check one: [ ]Mandatory [ ]Highly Preferred [ ]Slightly Preferred Reason for Priority: Project Impact Items in the section are subject to approval of software team. Estimated Budget Change:_____________________________________________________ Estimated Schedule Change:___________________________________________________ Notes Provide any other notes necessary.

  24. The Cross Reference • Typically the last section of the SRS • List items from the System Spec. • Tell which section of the SRS provides coverage. • Identify the items that contain risk. • Identify the items that will be designed with flexibility. • Identify the items that define the “Critical Path”

  25. Last Semester: 2 Columns

  26. this semester at least 3 columns A Table, in which the rows are a simple list of the individual capabilities of the end system, nicely numbered for reference later, and column 1 is the location of each requirement in the System Spec, and column 2 is the location of each requirement in the SRS. This table will serve you in the planning phase (as a task list), to assure that all items that need to be designed and coded are included. If you need to change your System Spec, then please do it.

  27. NEXT SEMESTER (CSE453) Development Vehicle • Development OS (may have been specified in System Spec) • Language (may have been specified in System Spec) • Editors, Syntax Checkers, Libraries • The Configuration Management and Version Control Systems • Specified for budgetary more than technical reasons.

  28. NEXT SEMESTER (CSE453) Execution Vehicle • A large undertaking if not specified in the System Spec. • SHOULD be decided with the customer before the SRS • Usually the first item in "how we plan to solve your problem"

  29. NEXT SEMESTER (CSE453) After the SRS • Critical Design • Module Level Details • Structure Charts / Object Charts • build the Integration Thread • Major Module • Interfaces • module-to-module • hardware to software • drivers to control (up levels of supervision)

  30. Can’t Go Back • Once an SRS is approved, changes become very expensive: • A specification change, leading to design changes, leading to coding changes, leading to schedule/budget changes, leading to testing changes and finally delivery changes • Catch specification mistakes in the specification phase. How? • In the System Spec and SRS • Use reviews