Managing Software Development (MSD) Term VI Elective

Toy Library System

PGP 2013-14

An entrepreneur has approached your development team to assist them in getting a business idea off the ground. They have discovered that there is a market for lending out toys. Just as someone might borrow a book or video and later return it rather than purchase the item which has limited value after they have read or watched it once, children often get bored with their toys. Having too many toys can be problematic as they take up space and present too many options to choose from for the child/parent. Many parents rotate toys, putting some away in longer storage and retrieving them after the child has become bored with the current set of available toys. However, toys can be very expensive (especially good quality ones that wont break), storage is often limited and the effort to manage this is high. The toy library is designed to address all of these issues.

The entrepreneur does not have any experience with software products. He knows that, like with other libraries, the system will need to keep track of all the toys they have purchased and ordered. This will include information about their purchase price, supplier, product codes and descriptions, age range, etc. Details about borrowers will also need to be maintained by the system. Limits on the number of items to be borrowed, length of borrowing times (which will differ for some items), overdue items, reminder notices, items on reserve, payments due, overdue payments, will need to be kept track of by the system. Managing the state of each toy, payments and client will be an important part of the system affecting the availability of the toy for lending.

The system will need to be easy to use by a non-technical person. The system can be a standalone application or use a web-based interface. The entrepreneur has no money (which is why he is looking for a way to make some), so your budget is zero. That eliminates your cost management, as you are implementing this on a probono basis.

MSD / Term VI Elective / PGP 2013-14

Deliverable 1:
A. Detailed Project Plan, B. Requirements Specification and C. Requirements Analysis. Turn-in date: 6th January 2014 (Monday) A. Detailed Project Plan (4 marks): This document (around (10) A4 sides) and should contain the following: 1. A detailed Development Plan, (2.5 marks) including a statement of purpose, the initial [given] situation, a full list of deliverables and milestones (major and intermediate), an initial schedule (Gantt Chart), an associated identification and allocation of resources, and a detailed description of how tracking and control are to be structured and managed. 2. A succinct Quality Plan, (1.5 marks) describing how quality-related issues are to be structured and managed throughout the duration of the project. Development Plan: This should include coverage of the following: Statement of purpose [for plan] and scope [of project] The givens - ie the problem statement, the set of deliverable dates and the group Development risks and their management Schedule - tasks, time-line (Gantt Chart), associated resource implications. Project resources - people, hardware, software, other resources Organisation - group roles and responsibilities (inc. reporting) Tracking and control mechanisms Reference to the Quality Plan Quality Plan: State clearly and specifically how quality issues are to be structured and managed by your team during your project. The quality plan should, at least, include some coverage of at least the following: Statement of purpose Management of quality issues - during development Problem reporting and corrective action Configuration management (versioning) Documentation Reviews and audits Tools and techniques Maintenance of project records Referenced documents (List all resources, including web links)

SV [AT] IIMTRICHY

Page 2

MSD / Term VI Elective / PGP 2013-14 B. Requirements Specification (4 marks): This document (around fifteen (15) A4 sides) and shall contain the following: 1. 2. 3. A Systems Requirements Specification (3 marks) (6-15 pages) Requirements Traceability Matrix (0.5 mark) (1-2 pages) List of assumptions (0.5 mark)(1 page)

The number of pages specified is indicative. You may actually need less or more number of pages. However, ensure that you include the necessary content without introducing irrelevant material. Develop an SRS: A sample SRS may be searched from the internet. A useful powerpoint presentation summarising the key points about SRS documents is available at http://www.ncst.ernet.in/education/apgdst/sefac/slides/SRS.PPT Following the standard the sections to be included are: 1 Introduction 1.1 Purpose (of the document) 1.2 Scope of product/system (including context diagram) 1.3 Definitions, Acronyms, and Abbreviations 1.4 References 1.5 Overview 2 Overall Description 2.1 Product Perspective 2.2 Product Functions 2.3 User Classes and Characteristics 2.4 Operating Environment 2.5 Design and Implementation Constraints 2.6 User Documentation 3 Requirements 3.1 Functional Requirements 3.2 Performance Requirements 3.3 Design Requirements 3.4 Other Non-functional Requirements Requirements Traceability Matrix (RTM): Set up an RTM with the following columns: Requirement-ID (from SRS) From Requirement-ID To Requirement-ID Type (Mandatory or Optional) There should be one row for each requirement. Dependencies between requirements and the direction are to be entered in From Requirement and To Requirement columns. This is important in case you need to modify and trace a requirement. In Type column, specify if the requirement is mandatory (essential) for the system or optional (extensional). Only include functional requirements in your RTM, as non-functional requirements apply to all functional requirements, that is they say how the functional requirement should be. For example, if the system must be portable, secure access, in the third year labs, written in Java, SV [AT] IIMTRICHY Page 3

MSD / Term VI Elective / PGP 2013-14 easy to use, quick to learn, etc then all the functional requirements must meet these nonfunctional requirements. List of Assumptions: This will help the client (and also ME) understand why you have done certain things. Please review the assumptions before submission. A poor assumption will not be a valid reason for poor analysis models. C. Requirements Analysis (4 marks): This document may contain the following: 1. 2. 3. 4. 5. Use Case Diagram (1 mark) (1 page). Use Case Description for each use case (1 mark) (4-8 pages). Analysis Class Diagram (0.5 mark) (1 page). Sequence Diagrams for each use case (1 mark) (5 pages). State Diagram for any objects with complex behaviour (0.5)(1-3 pages)

The number of pages specified is indicative. You may actually need less or more number of pages. However, ensure that you include the necessary content without introducing irrelevant material. Use Case Diagram: This is a graphic model showing the actors, the use cases and the relationships between them. One page should be sufficient. As a rule of thumb if the description of a use case is very short (e.g. one or two steps only) or very similar to another use case, then consider combining the use cases and describing the alternate courses of action within that use case. Structure the use cases into logical groupings. Remember its from the users point of view not the developers. Use Case Description: For each use case, there needs to be a corresponding textual description. Please use the template included on the Project Page. Sub-use cases can be combined into one use case description. For example, if you have a use case Maintain Client with sub-use cases Adding Client, Deleting Client, Viewing Client or Modifying Client, you can just write one use case description for Maintain Client and describe the differences by branches in the use case steps. Analysis Class Diagram: At the analysis stage you may not have discovered methods, boundary or control classes. Make sure any classes or methods on your sequence diagrams have been included on the class diagram. Full method signatures do not need to be given, but you can specify them now if you chose. Traversals (direction of relationship between classes) should not be decided yet. These should be shown in the design class diagram. The diagram must include: classes, attributes, associations inheritance and/or aggregation (as applicable) multiplicities

SV [AT] IIMTRICHY

Page 4

MSD / Term VI Elective / PGP 2013-14 Sequence Diagram: One sequence diagram for each use case description. It should be possible to read the description and follow what is happening on the diagram. The objects and messages must be valid and shown on the Class Diagram. State Diagram: A state diagram shows the life cycle of an object and thus all objects can be represented in a State Diagram. However, you are required to consider the life cycle of each object in your system and to submit diagrams for those that have interesting states or complex behaviour. One way to measure if a state is interesting is to consider whether you need to test that state before performing a particular action or if the state changes after an action is performed. What is interesting will depend on the application. In most cases when an object is updated or printed (updated and printed can be states themselves but are generally not very meaningful) that will not change more interesting states such as paid/unpaid, married/single or for sale/sold.

SV [AT] IIMTRICHY

Page 5

MSD / Term VI Elective / PGP 2013-14

Deliverable 2:
Detailed Design, Test Specifications, Revised Project Plan Turn-in date: 27th January 2014 (Monday) A. Detailed Design (5 Marks): This document (around thirty-five (35) A4 sides) and should contain the following: 1. System Design Document (5 pages) 2. User interface layouts (3 pages) 3. Window Navigation Diagram (2 pages) 4. Report layouts (2 pages) 5. Data definitions (3 pages) 6. Description of complex algorithms (2 pages) 7. Updated Use Case Diagram (2 pages). 8. Updated Use Case Description for each use case (4 pages). 9. Design Class Diagram (1-2 pages). 10. Updated Sequence Diagram for each use case (5 pages). 11. Updated State Diagram for any objects with complex behaviour (3 pages) 12. Updated Requirements Traceability Matrix (2 pages) 13. List of assumptions (1 page) The number of pages specified is indicative, but try to be concise and still complete. More number of pages essentially do not mean higher grades and neither fewer pages, a lower grade. System Design Document: This will include the basic architecture of the system and the high level strategy decisions. You may include a description of the: a) system architecture b) storage data strategy c) trade-offs and choices d) any concurrent processes and how they will be handled if any exist e) Package diagram showing the subsystems you will use User Interface Layouts: Show your proposed interface layouts you may use any diagramming tool or present a hand-drawing Window Navigation Diagram: Show how the different screens will link together and what triggers a transition from one screen to another. You may want to use activity diagrams for this purpose. Report Layouts: Outline your proposed report layouts: free hand or using tools Data Definitions: Create a table to show what data is needed to be stored in files/database. For each table/file show the name of the field, the primary key (if applicable), the field type and an example of data in this field.

SV [AT] IIMTRICHY

Page 6

MSD / Term VI Elective / PGP 2013-14

Complex includes: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

Algorithm Description: For each complex method, develop a description which Name Brief description Complete details such as type, input and output parameters Preconditions Post-conditions Events transmitted to other objects Other operations called Attributes set Response to exceptions Non-functional requirements

Updated Diagrams from Deliverable 2. Note that design classes, methods, concepts should now be included. Updated Requirements Traceability Matrix (RTM): Update the RTM from Deliverables 1 and 2. Include five new columns Use cases, Classes, Methods Packages Build Number. Under each of these list the use case, class, method, package, build number which relates to the realisation of the requirement. Build Number is which build of the system you intend to include that functionality. You should not plan to put everything into one build (version). You should consider incremental development even if the product is delivered at the end of a number of builds. The purpose of the RTM is to ensure that you have not forgotten any requirements in development of the system. List of Assumptions: This will help the client (and also ME) understand why you have done certain things. Please review the assumptions before submission. A poor assumption will not be a valid reason for poor analysis models. B. Test Specifications (3 Marks): This document must not exceed ten (10) A4 sides and should contain the following: 1. A description of the testing strategy (ies), unit and system, to be employed. 2. Test-case identification, made up of high-level test descriptions, features to be tested, identification of relevant test cases, and "pass"/"fail" criteria for each test case. 3. Test-case specifications, made up of test-case identifiers, test data - input specifications and output specifications. 4. Test plans, including a detailed test schedule, testing resources assigned, testing milestones and test deliverables. Please note that the system involves only a single hardware platform as specified by the client. So you may not consider multi-operability in your project. SV [AT] IIMTRICHY Page 7

MSD / Term VI Elective / PGP 2013-14

You may produce test designs and test case specifications at the component, systems and acceptance levels of testing. Acceptable documentation for this deliverable shall include: 1. Test design document: a) Identifier. b) Features to be tested. For each give traceability references back to requirements or design documents. c) List of test cases required. d) Pass/Fail criteria for each feature in b) and test case in c). Test case specifications: a) Identifier. b) Test description with references to the relevant places in the test design document. c) Input specifications. d) Output specifications. Test plans, covering scheduling and resourcing of all testing processes. C. Revised Project Plan (5 marks): Assume some schedule slips and that you have identified some risks. Discuss them in sufficient details. The following is required: 1. A revised and updated version of your project schedule, that takes into account any schedule revisions, covering the balance of the project, that have arisen since you submitted the Deliverable 1 schedule. 2. A careful and detailed explanation of all the schedule changes that have occurred. You may include, for comparison, a copy of the original schedule that you submitted for Deliverable 1. 3. An updated risks analysis, reflecting the present project status and progress to date.

2.

3.

SV [AT] IIMTRICHY

Page 8