1 / 74

CIS 245 Lab

CIS 245 Lab. CIS 245 Software Engineering Lab.

susankaminski
Download Presentation

CIS 245 Lab

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. CIS 245 Lab

  2. CIS 245Software Engineering Lab This lab accompanies the software engineering course to support the content in the course. The overall goals of this lab are to introduce examples of CASE tools that are used in the different software development stages. Students will learn tools from requirement, design and testing stages. Programming tools and skills will not be introduced in this lab as they are expected to have a separate lab

  3. Lab Objectives The objective of the lab is to provide students with the opportunity to: Apply software engineering processes and knowledge learned in the theoretical course in an actual project. Interact with some CASE tools to learn them and understand how they can help the development process in the different phases. Work in teams. Understand the different roles that can be played in a team, deal with team conflicts and work together toward a successful project.

  4. Software applications Used: Step1 : Software Requirement specification[ Rational Requisite Pro ] Step2 : Software Design [Rational Rose 2002] Step3 : Software testing [ Using NUnit]

  5. Student’s assessment Grading Policy Lab Assignment + Quizzes 25% First Exam 15% Second Exam 15% Attendance 5% Final Exam 40%

  6. Step1Rational RequisitePro

  7. What is “Rational Requisitepro” ?? • Rational Requisitepro is a Rational Requirements Management Tool. • Rational Requisitepro describes the components of the software. • You will have an opportunity: • To use some of the templates provided with this program to document a project, as packages, queries, and documents.. • Or you can attach these project documents with other rational tools as UML, RUP…

  8. Why Using “Rational RequisitPro”? RequisitePro is used for managing requirements which is the most significant factor in delivering projects on time, on budget, and on target. RequisitePro helps projects succeed by giving teams the ability to manage all project requirements comprehensively and facilitating team collaboration and communication. RequisitePro enables you to organize, prioritize, trace relationships, and easily track changes to your requirements, The program’s unique architecture and dynamic links make it possible for you to move easily between the requirements in the database and their presentation in Word documents.

  9. Key Concepts in RequisitePro • The main concept is “Requirements” • Project • Views use standard query techniques on the database of requirements to show information and relationships. Each view is composed of the query that generates the information to be displayed and the view type • There are four predetermined formats for viewing the information as follows • Traceability Matrix • Traceability Tree (Traced into) • Traceability Tree (Traced out of) • Attribute Matrix • Relationships • Documents

  10. The Project In Rational RequisitePro, the concept of a project is used to provide the groundwork for organizing and effectively managing requirements. Each project includes the following: a database, documents, packages, document types, requirements, requirement types, attributes, attribute values, discussions, traceability relationships, saved personal and project-wide views. Only one project can be opened at a time. Numerous requirements documents can belong to a project; that means different users can edit different documents simultaneously.

  11. Project Templates Several project templates are shipped with RequisitePro Examples Use-Case Template: Use cases are particularly applicable to object-oriented software design using the Unified Modeling Language and for applications that are user-intensive. Traditional Template: This template includes a traditional Software Requirements Specification outline rather than use cases. Composite Template.

  12. How to start using “Rational RequisitePro”? Program > Rational Software > Rational RequisitePro > Use Case Template To create new project…

  13. Creating a new project • Select traditional template and click OK. The Project Properties window opens as shown in the figure bellow. Software Requirement Specification and Rational RequisitePro

  14. Creating a new project • Enter the name of the project, select a directory, select a database, and optionally provide a description. Use the built-in Microsoft Access database. This is also the location where you would select a suitable SQL Server or Oracle solution. Click Properties to define the login and database identities. Software Requirement Specification and Rational RequisitePro

  15. Project packages • The packages within a RequisitePro project are used to organize the different components in the project. • Packages can contain one or more of information: • Requirements: the main data type in the project. • Documents: based on a template, a bare document or the requirements list. • Views: views, based on separate queries, of the list of requirements. • For example, in the traditional project template there are three packages used to record different requirement information: • Software requirements: the final list of requirements that are used for the project. • Features and vision: the list of features for the project. • Stakeholder requests: the list of requests for features from stakeholders. Software Requirement Specification and Rational RequisitePro

  16. Packages • Once the project template has been copied into your new document, a window similar to the one shown in the figure below appears. Software Requirement Specification and Rational RequisitePro

  17. RequisitePro explorer window • The figure below shows a document with the software requirements section expanded. Software Requirement Specification and Rational RequisitePro

  18. Creating requirements within RequisitePro • Start by building a list of requirements. The steps below show you how to add the first requirement to the project. • To create the first requirement: • Right-click within the tree and select New > Requirement, or select the same menu option from the main File menu. A window like the next figure opens. Software Requirement Specification and Rational RequisitePro

  19. Requirement properties • All requirements are recorded within a folder. This can either be the root folder (not generally recommended) or one of the packages. Because you are creating basic software requirements at this stage, click Browse and select the Software Requirements folder. Software Requirement Specification and Rational RequisitePro

  20. Creating requirements within RequisitePro (cont…) • Specify the requirement type. This is a notional marker that highlights the requirement as a specific type but has no bearing on where the requirement is stored. The type affects on what attributes are stored with the attribute and ultimately that information is used in queries and views to link and trace the sequence and source of information through the system. For the purposes of this walk through, use the Software Requirement type. • Give the requirement a name. This should be enough to identify the item within the system. “The user should have the ability to enter a Username into the database into this field.” Software Requirement Specification and Rational RequisitePro

  21. The final list of requirements • The list should look like the one shown in the figure bellow. Software Requirement Specification and Rational RequisitePro

  22. Working with Document Types • A Document Type is a document structure; based on document outlines. • The common Document Types are: • Vision. This document gives the overall view of the system. • Glossary. It is important that all stakeholders use consistent terms to express requirements. • Test Plan. This document describes the target-of-test (components, application, system) and its goals; the stages of testing; and the types of testing that will be addressed by this plan. If you have installed Rational TestManager • Requirements Management Plan. This document sets out guidelines for establishing the requirements documents, types, attributes, and traceability in order to manage the project requirements. • Use-Case Specification. Use cases serve as a format to express functional requirements in sequence. Use cases are especially good at documenting functional software requirements. • Supplementary Requirement Specification. This document captures any requirements that cannot be tied directly to any specific use case, and especially many of the nonfunctional requirements and design constraints.

  23. Adding further requirements • Repeat this sequence with the remaining requirements from the list, as outlined in this table. All the requirements should be stored within the same Software Requirements folder and all should be of the Software Requirement type. Software Requirement Specification and Rational RequisitePro

  24. Adding further requirements • You can see from the previous figure that each requirement is given a unique reference number. • These numbers are used to help track and trace requirements through the system. Software Requirement Specification and Rational RequisitePro

  25. Alternative requirement types • The project template you are using includes a number of pre-defined requirement types: • Requirement types define the attributes and other information that is stored with a requirement in the database. • Requirement types are configured on a project-by-project basis or within a project template. Software Requirement Specification and Rational RequisitePro

  26. Add or change requirement type: Project properties • To add or change the type definitions: • Open the properties for the project either by right-clicking on the project and choosing Properties or by double-clicking on the root project. A project properties window appears like the one shown in the figure bellow. Software Requirement Specification and Rational RequisitePro

  27. Add or change requirement type: Requirement types tab • Click the Requirement Types tab. Software Requirement Specification and Rational RequisitePro

  28. Add or change requirement type: The requirement types tab • To add a new type, click the Add or edit an existing type. You can see from the previous figure that a Developer Requirement type has been added. The basic properties for this type are shown in the figure below. Software Requirement Specification and Rational RequisitePro

  29. Add or change requirement type: alternative requirement types • Duplicate the information in the previous window to create the Developer Requirement type. The color and style are used when viewing the requirements in reports and documents so you can use this to help identify the type. Software Requirement Specification and Rational RequisitePro

  30. Requirement attributes • Flowing is a list of the attributes defined within the project for the Software Requirement: • Priority: High, Medium or Low. • Type: the type of requirement (usability, performance, etc). • Status: whether the requirement has been approved or incorporated into the project. • Difficulty: a rough guide to the difficulty that would be experienced to achieve the requirement. • Stability: a guide to the stability of the requirement within an active project. Software Requirement Specification and Rational RequisitePro

  31. Requirement attributes (cont…) • Risk: a guide to the risk associated with implementing the project. For example, there might be a high developmental risk if the requirement would require changes to other parts of the system (thereby reducing stability). • Enhancement Request: the information sourced from a Rational project if this RequisitePro project is part of a Rational project. • Defect: generated by a Rational project during defect management/testing. • Contact Name: for the source of the requirement. • Obsolete: an indication of whether the requirement is obsolete. Software Requirement Specification and Rational RequisitePro

  32. Specifying the attributes for a requirement type • Add a development team field to the Developer Requirement type: • Open the project properties. • Change to the Attributes tab (shown in the figure in the next slide) and then select the Developer Requirement type from the window. A list of the attributes currently defined for the type will shown. Software Requirement Specification and Rational RequisitePro

  33. Specifying the attributes for a requirement type Software Requirement Specification and Rational RequisitePro

  34. Adding an attribute to a requirement type • Click Add. Attributes have a label (the field name you'll populate when you create a requirement), a type, and an optional list of values that are used within a popup or list. The type is a field type just as in a database and can be an integer, floating point, text string, date, time, URL or a list, either single or multiple selection. Select the List (Single Value). Populate the list using the information shown in the figure in the next slide. Use Return to separate the values. Software Requirement Specification and Rational RequisitePro

  35. Adding an attribute to a requirement type Software Requirement Specification and Rational RequisitePro

  36. Creating requirement documents • If you select to generate the requirements in Word, it is probably a good idea to generate and record all requirements directly within Word, although it's certainly not a requirement. • To generate requirements from within a Word document: • Generate a new document, or open an existing document if one was created as part of an existing project template. • To create a new document, select File > New > Document or right-click on the tree view of the project and select the same options. A window opens as shown in the figure in the next slide. Software Requirement Specification and Rational RequisitePro

  37. Document properties window Software Requirement Specification and Rational RequisitePro

  38. Creating requirement documents • Enter a name for the document (as it appears in the project) and provide a description of what the document contains. You'll be using a document for your Developer Requirements specification so name the document accordingly. As you can see from the sample, this document was created in a new package that has not been created yet, so create it in the root package. • For the document type, select the Software Requirements specification. This creates a document using the corresponding Word template. • Click OK to create the document and open the template within Word. Software Requirement Specification and Rational RequisitePro

  39. Populating the document Software Requirement Specification and Rational RequisitePro

  40. Adding requirements from within Word • A new toolbar is available within Word when you are editing a RequisitePro document (see the figure below). You'll need this― or the RequisitePro menu― as you create requirements directly in the document. Software Requirement Specification and Rational RequisitePro

  41. Adding requirements from within Word (cont…) • To create a requirement within the document: • Enter the text description for the requirement directly into the Word document. Enter “The Database will hold information about the recipe, recipe ingredients and recipe method” for this example. • Select the text you just typed into the document and then click New Requirement (the first square bracket ([]) button), or select New Requirement from the RequisitePro menu. • Enter a name for the requirement, specify the requirement type, and ensure that the Package and Location information within the requirement properties are correct (see the figure in next slide). These last two properties should automatically be populated based on the location of the document you are editing. Software Requirement Specification and Rational RequisitePro

  42. Creating a new package • To create a new package to help track developer requirements in the project: • Right-click in the explorer and select New > Package or select the same option from the File menu. A window opens, as shown in the figure in next slide. • Give the package a name. You're creating a Developer Requirements section so enter Developer Requirements into the Name field. In the Description field, enter Requirements specified by the developer based on stakeholder and user requirements. Software Requirement Specification and Rational RequisitePro

  43. Case Study:ClassicsCD.com Web Shop System (1) THE SYSTEM: The ClassicsCD.com Web Shop system is an application available on the World Wide Web. ClassicsCD.com is intended to provide a new channel of sales for ClassicsCD, to supplement the existing bricks-and-mortar retail operation. THE PRODUCT: ClassicsCD system wants to integrate its Web shop with the corporation’s order processing and fulfilment system. We envision a smaller scale supply-chain management system that integrates the Web application with all the stores, suppliers, and warehouses. This includes the following: A Home Shopping e-commerce system A warehouse system An order processing system

  44. Case Study:Modify the Vision Document (2) Go to: Features and Vision > vision document file Add: The descriptive part of the system, problem domain, vision and objectives, and users description. Note:You can add some Requirements in this part as system or product features, organizational standards and environmental conditions. Some Examples of these Requirements

  45. The Use-Case A Use-Case is a sequence of actions or events which a system performs that yields an observable result of value to a particular actor. A Use-Case documents Functional Requirements from the perspective of the user. Each Use-Case is described by its Flow (flow of events); the Basic flow and/or Alternative flows. Each Use-Case has its own special requirements, preconditions and/or postconditions. Any Use-Case could be extended to other Use-Cases by the extension point. Go to Example of “Basic and Alternative Flow of Use-Case”

  46. Defining Use-Cases in Use-Case Package Use case Package > new > package Or > Document (Go to slide 17) Modify the properties of the Document that you create to be a Use-Case specification document. (Go to slide 18) Modify the contents of the Use-Case Document to contain description of the Use-Case, all details of the Basic Flow and Alternative Flows of Use-Case, and conditions that should be followed.

More Related