代写 MQ ISYS254 – Applications Modelling and Development

MACQUARIE UNIVERSITY
Faculty of Science and Engineering
Department of Computing
 
ISYS254 – Applications Modelling and Development
2016 - Semester 1
 
ASSIGNMENT 1 – Individual
20 marks


NOTE: Two (2) due dates
 
Requirements: First Deliverable
Due by Monday 21^st March 5pm
10 Marks


Analysis and Modelling: Second Deliverable
Due by Friday 8th April 9am
15 Marks
 
See submission instructions for each deliverable.

About the marking

This assignment has been broken into two separate deliverables, the first worth 10% the second worth 15%. Following marking of the first deliverable, some specific hand-written comments will be provided on the submissions and a set of general comments will be discussed in the lectures immediately following the submissions and possibly sent out via email.  Feedback will be given on the final deliverable via email and on the submissions. Ensure you collect your marked submissions as you do not want to make the same errors again in the exam. As no one solution is correct, but many incorrect solutions are possible, the top two/three student submissions will be made available to other students, with their permission.
You should revise the unit content for Weeks 1-6 and the feedback from the assignments to study during the mid-semester teaching break for the Midterm Examination worth 20% of the assessment.
Learning Activities:
PART I
Identify appropriate requirements engineering methods.
Follow a documentation standard.
Write and validate a requirements document (SRS).
Identify the scope of the system and model the scope.
Get some initial practice (and early feedback) with modeling requirements i.e. Use Case Diagrams
 
PART II
Revise your understanding based on PART I feedback.
Understand how UML relates to Object Oriented code.
Understand how the different UML diagrams relate to one another.
Use appropriate tools and techniques to prepare and validate analysis models.

Problem statement for the assignment

 

REQUIREMENTS: First Deliverable Due by Monday 21st March 5pm
10 Marks
 
Task 1: Requirements engineering (1/2-1 pages) (2 marks):

• Describe suitable techniques for gathering requirements (e.g. surveys, interviews, JAD, user stories, etc) appropriate to the problem you are trying to solve. Say why you suggested those (and not others).

(0.75 mark)

• Describe the requirements elicitation, specification and validation you have actually done to come up with the SRS. What data did you collect and how did you use it? (0.75 mark)
• Write 2 user stories (As a <user>, I want <….>, [so that …..]. (0.5 mark)

 
Task 2:  System engineering (high-level) design and models (2 marks):

• Draw a Context diagram (level 0 Data Flow Diagram) which depicts data flows, the system scope and entities. (1 page) (1 mark)
• Draw a Use Case diagram. This is a graphic model showing the actors, the use cases and the relationships between them. (1 page) (1 mark)

 
Use any UML CASE tool to draw diagrams.
 
 
Task 3: Develop a Software Requirements Specification (5 marks) (4-10 pages): This should follow the IEEE standard below:
1 Introduction (1 mark) (1-3 pages)
1.1 Purpose of the requirements document
1.2 Scope of the product (include your context diagram here)
1.3 Definitions, Acronyms, and Abbreviations
1.4 References
1.5 Overview of the remainder of the document
2 Overall Description (1 mark) (1-3 pages)
2.1 Product Perspective
2.2 Product Functions
2.3 User Classes and Characteristics
2.4 Operating Environment
2.5 User Documentation
3 Requirements (3 marks) (1.5- 5 pages)
3.1 Functional Requirements
3.2 Performance Requirements
3.3 Design Requirements
3.4 Other Non-functional Requirements
3.5 Future Requirements
 
You may want to look at, but please do not pay for the IEEE standard (The most widely known requirements document standard is IEEE/ANSI 830-1998 (IEEE, 1998). You can modify the template provided on iLearn or other similar one which follows the standard. Make sure your document passes the Requirements Review see http://www.SoftwareEngineering-9.com/Web/Requirements/Reviews.html
 
Task 4 (1 mark) Requirements Traceability Matrix (RTM): Set up an RTM with the following columns:
Requirement-ID (from SRS)
From Requirement-ID
To Requirement-ID
Type (Essential or Extensional)
 
The purpose of the RTM is to ensure that you have not forgotten any requirements in development of the system.
There should be one row for each requirement. “From Requirement” and “To Requirement” indicate dependencies between requirements and the direction. This is important in case you need to modify and trace a requirement. In “Type” you need to specify if the requirement is essential (i.e .mandatory) for the system or extensional (i.e. desirable/optional).  Essential requirements will be part of version 1, extensional requirements will be considered for future versions of the software.
 
Task 5: List of Assumptions (max. 1 page): This will help the marker/client understand why you have done certain things and clear up any misunderstandings. Please review the assumptions before submission.  A poor assumption (one clearly contrary to the information you have been provided and common sense) will not be a valid reason for poor requirements specification/analysis/design models. (-0.25 for non-submission)
 
ITEC654 student ONLY. Task 6 Requirements and Systems Engineering (2-4 pages) (4 marks) (total marks will be scaled out of 10):
 
Describe and discuss techniques for gathering requirements. When are each appropriate? Provide examples (including questions or activities) of how each could be used for the current problem.  (1-2 pages) (1.5 mark)
 
Outline the system you envisage (that is, how will the software relate to other parts of the system such as people, hardware, processes/work activities and data) and other systems in the organisation. Diagram/s may help depict your ideas. What level of management and decision-making is related to this system?  (1-2 pages) (1.5 mark)
 
Comment on whether your document passes the Requirements Review at http://www.SoftwareEngineering-9.com/Web/Requirements/Reviews.html (0.5-1 page) (1 mark)
 
What to submit for Part I
Create a single Word document that includes your answers in the following order:
Task 1: Questions and your answers.
SRS (include context diagram in SRS section 1.2)
Use Case Diagram
RTM
Assumptions
ITEC654 students only: Task 6: Questions and answers.
 
(1) In the ISYS254 assignment box on the ground floor of building E6A submit a single printed document (preferably stapled rather than in a folder). The deliverable will be marked from this paper copy, and
(2) electronically on iLearn, submit a .pdf file containing all documents and diagrams. This file is a backup in case of a missing paper copy.
 
Analysis and Modelling: Second Deliverable Due by Friday 8th April 9am
(15 Marks)
 
ANALYSIS MODELS
Based on the problem description and consistent with the SRS, create the following analysis diagrams which model the problem domain.
 
Use any UML CASE tool to draw all diagrams.
 
HINT: For all documents/models in this deliverable remember you are modelling the problem – not the solution. So,  for example,  on your use case description don’t say “user clicks the submit button” because you don’t know yet that there is a submit button – that is part of the solution. Instead say “the user submits the order/request”.
 
Note: A full model requires a use case description and sequence diagram for every use case which will elaborate the full functionality of the system and also reveal all the classes/objects and the public methods needed to achieve this functionality.  However, as this is an individual assignment, you will just create one sequence diagram, use case description and state diagram.
 
Task 1: (1.75 marks) Updated Use Case Diagram: Update your use case diagram according to feedback and your revised understanding. While you are not asked to write all use case descriptions, think about what steps are included in each one so you can identify overlaps, missing use cases or relationships between them.
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 using <<includes>> to show reused/common functionality in more than one use case and the generalization arrow to show hierarchical relationships where a higher level use case can be broken into more than one lower level detailed use case (e.g. Maintain Customer <<includes>> Create Customer; Delete Customer, Update Customer .  For exceptions or functionality not used in the “normal course of events” use the <<extends>> relationship. Remember Use Cases concern the functional view from the users’ point of view – not the developers. Include system boundary.
 
Task 2: (1.75 mark) Use Case Description: Choose one use case and provide a corresponding textual description using the template provided with this specification.  Sub-use cases can be combined in the one use case as long as the differences can be sensibly articulated.
 
Task 3: (4 mark) Analysis Class Diagram: At the analysis stage you would normally not have considered Boundary/Presentation/View, Control/Database/Foundation classes or other classes needed for the design and implementation phases. Thus I only expect to see Entity classes. These are classes that stakeholders, especially system users, would recognise as concepts which exist in their domain e.g. patients, beds, nurses, doctors, medication, etc in the Hospital Domain. Tip: Make sure any classes or methods on your sequence and state diagrams have been included on the class diagram.
 
Full method signatures do not need to be given on the analysis class diagram, but you can specify them now if you chose. Do not show traversals. The diagram must include: classes, attributes, labeled associations (or associations with roles), inheritance and/or aggregation (if applicable), multiplicities.
 
Task 4: (3 mark) Sequence Diagram: Draw a sequence diagram for the same use case you chose for your Use Case Description. Tip: The objects and messages must be shown on the Class Diagram.
 
Task 5: (2 marks) State Diagram: A state diagram shows the life cycle of an object and thus all objects can be represented in a State Diagram. However, many objects have boring lives and it is not necessary to explicitly model them. For this deliverable consider each class on your class diagram and choose one objects (i.e. instances of a class) with interesting states and a draw a state diagram for those objects in Enterprise Architect. Tip: The object and messages must be shown on the Class Diagram.
 
Task 6: (2 marks) Linking Class Diagram and Code: Review and run the Java code that has been created to date for this system. Make sure that your class diagram includes all of those classes. List differences between your class diagram and the code (e.g. different classes, methods, associations) and why your model is different (e.g. because of additional/other features you have included in your SRS).
 
Task 6: (0.5 mark) Updated Requirements Traceability Matrix (RTM): Set up an RTM with the following columns:
Requirement-ID (from SRS)
From Requirement-ID
To Requirement-ID
Type (Essential or Extensional)
Use Case/s
Classes
Build No
 
Update the RTM you previously submitted and add the additional columns. Under the headings Use Case and Classes list the names relevant to that requirement. Please include a Build Number which is the build of the system (ie compiling all the parts together into an executable) in which you think that functionality should be included.  Builds are planned because you should not put everything into one final build. A build is like a version/release but usually smaller and designed for internal purposes rather than for the client. Since you are not doing any implementation just make a guess at what you think should be implemented in what order and combination.
 
Task 7: List of Assumptions (max. 1 page): This will help the marker/client understand why you have done certain things and clear up any misunderstandings. Please review the assumptions before submission.  A poor assumption (one clearly contrary to the information you have been provided and common sense) will not be a valid reason for poor requirements specification/analysis/design models. (-0.25 for non-submission)
 
ITEC654 students ONLY. Task 8: (6 marks) Activity Diagram and Future Enhancements: An activity diagram can be used to model business processes, decision processes, business rules or logic. Identify and design one or two business processes or decisions needed by MULS and model them as an activity diagram.  Include a written description of the process/rules that is consistent with your diagram. (2.5 marks)
 
Provide an explanation of what changes need to be made to the design and code to support the future changes you suggested in PART I. (3.5 marks)
 代写 MQ ISYS254 – Applications Modelling and Development
 
What to submit for Part II
 
Create a single Word document that includes your answers in task number order. Make sure you label each diagram/task.
 
(1) In the ISYS254 assignment box on the ground floor of building E6A submit a single printed document (preferably stapled rather than in a folder). The deliverable will be marked from this paper copy, and
(2) electronically on iLearn, submit a .zip file containing all documents and diagrams. This file is a backup in case of a missing paper copy.