1 / 33

CS 501: Software Engineering

CS 501: Software Engineering. Lecture 9 Requirements 3. Course Administration. Feasibility Study Everybody should received comments shortly. Teaching Assistants have been assigned. Quiz 1 Uncollected answer books are at the reception at 301 College Avenue.

echan
Télécharger la présentation

CS 501: Software Engineering

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. CS 501: Software Engineering Lecture 9 Requirements 3

  2. Course Administration Feasibility Study Everybody should received comments shortly. Teaching Assistants have been assigned. Quiz 1 Uncollected answer books are at the reception at 301 College Avenue.

  3. Discussion of Feasibility Study General Who will read the feasibility study? What is needed to decide to go ahead? Scope and understanding of project Statement of the task Preliminary requirements and technical analysis Deliverables and business considerations Confidence Outline plan. Does it inspire confidence? Visibility plan.  How will progress be reported?  Risk analysis. How are the risks to be minimized?

  4. Quiz 1 (c) A U.S. government agency, which manages huge numbers of documents, has received funds to build a large-scale computer system. The agency proposes to use a waterfall model of software development, but an independent study recommends a phased development using iterative refinement in the first phase and a waterfall model in the second. [On the next three slides, a short answer is given in Roman type. Material in italic extends the short answers.]

  5. Quiz 1 (c) i Before this system is implemented some difficult technical choices have to be made. How much should the choice of technology be considered during the feasibility study? During the feasibility study, it is necessary to know that there is at least one technical approach that would allow the system to be built. It should be studied in sufficient detail to allow estimates of costs and time table. If there appear to be several very different technical approaches possible, more than one might be analyzed in sufficient detail to understand the implications for the costs and timetable. In this project, the feasibility study should also plan the process by which the technical decisions will be made.

  6. Quiz 1 (c) ii These technical choices are one of the reasons that iterative refinement is recommended for the first phase of development. Why? The first iteration will use the team's initial technical knowledge, but will likely show weaknesses in the approach chosen. Subsequent iterations will replace or improve aspects of the technical choices until a version is established that meets the requirements of the project. A waterfall model is unsuitable because of the large-scale changes that may need to be made. Because of uncertainty, it is difficulty to judge the cost and timetable of the project until this stage is complete.

  7. Quiz 1 (c) iii What is the advantage of using the waterfall model in the second phase? The waterfall model with feedback is an effective way to build a system that is well understood, so that few changes are likely to be made in either the requirements or the design. At its best, a waterfall process results in each stage being done once and being done well. For this system, the iterations made during the first phase should have created a high level of understanding and agreement about the entire system.

  8. Software Development Principles and Practices Software development Software development is a craft. Software developers have a variety of tools that can be applied in different situations. Part of the art of software development is to select the appropriate tool for a given implementation

  9. Modeling Techniques for Requirements Analysis and Definition The craft of requirements analysis and specification is to select the appropriate tool for the particular task. • A variety of tools and techniques. • Many are familiar from other courses. • There is no correct technique that fits all situations. As you build understanding of the requirements through scenarios and use cases, use modeling tools to specify requirements. The models provide a bridge between the client's understanding and the developers.

  10. Decision Table: Bad Example University Admission Decision High SAT T F F F F F High grades - T F F F F Sports - - T T F F Recommendations - - T F T F Reject X X X Accept X X X Note that the rules are too vague.

  11. Decision Table: Good Example University Admission Decision SAT > S T F F F F F GPA > G - T F F F F Athletics code =  - - T T F F Recommendations > A- - - T F T F Send rejection letter X X X Send acceptance letter X X X Note that the rules are now specific and testable.

  12. Data-Flow Models An informal modeling technique to show the flow of data through a system. External entities Processing steps Data stores or sources Data flows

  13. Data-Flow Example: University Admissions Rejection Application form Completed application Receive application Evaluate Applicant Acceptance Shows the flow, but where is the data stored?

  14. Data-Flow Example: Assemble Application Stage Acknowledgment Acknowledgment Application form Completed application AND Evaluation request Initiate evaluation Receive Applicant AND Does this model cover all applications? Are there special cases? Supporting information Applicant database Pending database

  15. Data-Flow Example:Process Completed Application Stage The data-flow diagram will need specification of the decision-making process. Rejection Evaluation request Acceptance Offer Financial aid Evaluation Special request Applicant database

  16. Procedural Models: Flowchart An informal modeling technique to show the decisions and paths that data takes through a system. Operation Decision Manual operation Report

  17. Form received Database record Update database Flowchart: University Admissions F T New? Complete? F T Evaluate Notify student Notify student

  18. Procedural Models: Pseudo-code An informal modeling technique to show the logic behind part of a system. Example: Check project plan check_plan (report) if report (date_time) > due_date_time then error (too_late) if report (client) = none then error (no_client) if report (team) < min_team or> max_team then error (bad_team) if error() = none then comments = read_report (report) return (comments (text), comments (grade)) else return error()

  19. Entity-Relation Model A requirements and design methodology for relational databases • A database of entities and relations • Tools for displaying and manipulating entity-relation diagrams • Tools for manipulating the database (e.g., as input to database design) Warning: There is much confusion about definitions and notation

  20. Entity-Relation Diagram An entity A relation between entities An entity or relation attribute An inheritance relation

  21. CS501 Student Example: CS 501 Project Major Client 0:1 1:n Student Client team member Project 0:n 0:1 1 Tech contact 5 to 7 Member of

  22. Example: Schema for Web Data CS 501 Spring 2005

  23. MARC Format for Books The MARC format defines a set of tagged fields that are used to catalog books in libraries. Here are some examples. • 001 Control number • 245 Short title • 260 Publisher • 650 Subject heading • 650 Subject heading • 700 Author Suppose you wish to use a relational database to store MARC records.

  24. Part of an Entity-Relation Diagram for MARC 0:n Book Author of 0:n 1 0:n Creator Editor of 0:n Describes 1 0:n Catalog record Subject heading 1:n Is about Short title Control numb

  25. Data Dictionaries A data dictionary is a list of names used by the system • Brief definition (e.g., what is "date") • What is it (e.g., number, relation) • Where is it used (e.g., source, used by, etc.) • May be combined with a glossary As the system is implemented, the data dictionary in the requirements is input to the system data dictionary, which is a formal part of the system specification.

  26. Event 1 Event 1 A A Event n Event n Petri Nets A Petri Net models parallelism Event f(A; E) S A S f(A; E1,..,En) S S . S1 . f(A; E1,..,En) S1,..,Sm Sm

  27. Transition Diagrams A system is modeled as a set of states, Si A transition is a change from one state to another. The occurrence of a condition, Ci, causes the transition from one state to another Transition function: f (Si, Cj) = Sk Example 0 S1 S2 1 0 1 0 S3 1

  28. Therapy Control Consol: Scenario "The set up is carried out before the patient is made ready. The operator selects the patient information from a database. This provides a list of radiation fields that are approved for this patient. The operator selects the first field. This completes the set up. The patient is now made ready. The lock is taken off the machine and the doses with this field are applied. The operator then returns to the field selection and choose another field."

  29. Therapy Control Consol: Finite State Machine Example: Radiation Therapy Control Console You are developing requirements for the operator's control console. In a client interview, the client describes the dangers inherent in using the machine. The operator must follow a strict procedure before the machine is ready to run. You use a finite state machine to specify the procedures. This shows the client that you understand the requirements and specifies the procedures for the developers.

  30. State Transition Diagram Discuss each state and transition with the client. Select field Start Enter Enter (lock off) Beam on Patients Fields Setup Ready Stop (lock on) Select patient

  31. Therapy Control Consol: State Transition Table Select Patient Select Field lock on lock off Enter Start Stop Patients Fields Setup Patients Fields Setup Fields Ready Patients Beam on Patients Ready Fields Setup Beam on Ready Setup

  32. Prototyping Requirements Rapid prototyping is the most comprehensive of all modeling methods A method for specifying requirements by building a system that demonstrates the functionality of key parts of the required system Particularly valuable for user interfaces

  33. A Note on Object Models This course teaches object models as a tool for design. Some people recommend object models for requirements definition, but it is difficult to use them without constraining the system design. Flow charts and finite state machines are supported by UML as design models, but can also be used for requirements. *

More Related