Methodologies - regular stream

.docx

School

Centennial College *

*We aren’t endorsed by this school

Course

313

Subject

English

Date

Feb 20, 2024

Type

docx

Pages

6

Uploaded by UltraPorcupine4095

Report
School of Engineering Technology and Applied Science Information and Communication Engineering Technology Software Development Project II (COMP313) Methodologies (10%) Due Date: Friday of Week 4 by 11:59pm (late penalty: 20 pts. per day) In this deliverable, the focus will be to kickstart your project based on the Agile paradigm and elements that will eventually be contents in the TAC technical report. The following sections comprise this deliverable: 1.0 Abstract (5 pts.) The Abstract summarizes in one paragraph of 200 words or less, the major aspects of the entire project in a prescribed sequence that includes: a) the overall purpose of the study and the problem(s) you investigated, b) the basic design of the project, c) major results of the project, and d) a brief summary of your interpretations and conclusions. The specific grading criteria 1 are as follows: ● Does the Abstract state what the Technical Report (TR) is about? [2 pts.] ● Does the Abstract state why the TR is significant? [1 pt.] ● Does the Abstract provide a brief description outlining a solution? [2 pts.] 2.0 Introduction (5 pts.) The Introduction primarily elaborates on the technical problem and the motivation for the project. It addresses the objective and the scope of the project. The specific grading criteria are as follows: ● Does the Introduction clearly state the technical problem? [1 pt.] 1 Answering “yes” to each of the questions in this grading criteria (same for other grading criteria for all deliverables in this course) will get you full marks. If there is no reference to the amount of pts (i.e., points) deducted, it means that either full marks will be received, or a zero will be received. A zero would be due to incorrect, missing, or nonsensical submission.
● Does the Introduction describe the motivation for the project? [1 pt.] ● Does the Introduction describe the scope of the project (i.e., what is included and/or omitted)? [1 pt.] ● Does the Introduction describe the objective of the project? [1 pt.] ● Does the Introduction discuss what unique problems were encountered in doing or interpreting the work performed? [0.5 pt.] ● Does the Introduction discuss unique approaches proposed in the study? [0.5 pt.] 3.0 Architecture: Development Perspective (15 pts.) Although there are many approaches to modelling the architecture of a system (see for example 4+1 Architectural View Model ), the architectural approach we adopt is the development perspective of the software architecture that is a simplified diagram that illustrates the major software and hardware components of the proposed system and how the various components interact with each other. Figure 1 is a sample architectural diagram of a project that students from my past class worked on with Samsung Canada.
Figure 1: Sample diagram of development perspective of software architecture. The specific grading criteria are as follows: ● Does Architecture diagram show all hardware components? For each missing component, 0.5 pt will be deducted [2.5 pts.] ● Does Architecture diagram show all software and/or logical components? For each missing component, 0.5 pt will be deducted [2.5 pts.] ● Does Architecture diagram accurately depict all directional data flow lines with appropriate labels? For each incorrect data flow line, 0.5 pt will be deducted [2.5 pts.] ● Does the Architecture diagram include a legend? [2.5 pt.] ● Does the Architecture diagram include supporting documentation that discusses how the various software and hardware interact (i.e., communicated)? [5 pts.] 4.0 User Role Modelling (10 pts.) Working with real users (i.e., customers) will strongly improve your likelihood of delivering the desired software. However, even with real users there is no guarantee that you have the right users or the right mix of users. The entire team takes part in coming up with a list of potential roles that will eventually be consolidated. After consolidating the identified roles, add details to the role cards. Minimally, the following must be considered: ● The frequency with which the user will use the software. ● The user's level of expertise within his/her domain. ● The user's general level of proficiency with computers and software. ● The user's level of proficiency with the software being developed. ● The user's general goal for using the software. Some users are after convenience, others favor a rich experience, and so on. The specific grading criteria 2 are as follows: ● Is coverage of user roles an overcomplete set (initial set from brainstorming)? [2 pts.] ● Is the number of initial clusters minimized (organization of initial set)? [1 pt.] 2 Answering “yes” to each of the questions in this grading criteria (same for other grading criteria) will get you full marks.
Your preview ends here
Eager to read complete document? Join bartleby learn and gain access to the full version
  • Access to all documents
  • Unlimited textbook solutions
  • 24/7 expert homework help