Description
The first two point are complete(please see the attached). I need help for the project only for point (3,4 and 5)
Summary
This project provides an opportunity for students to turn their theoretical knowledge of systems analysis and design into practical experience by completing a set of deliverables to complete activities in the ‘Design’ stage of the SDLC for a proposed system. It is anticipated that group members will need to conduct additional research to explore course topics in greater depth to adequately create the deliverables required for the project. Except for Trello, no tool, software, or utility is a requirement; groups must agree upon, as needed, the tools they wish to use to complete the project. Time at the end of each class session will be allocated for Project Workshops, where breakout room for each group will be provided, and the instructor will answer questions and drop in to rooms to check up on progress.
This project will require collaborative efforts, as well as individual contributions. As such, additional group meetings and communication will likely be necessary outside of the time allocated for project workshops. Each group is expected to coordinate such activities on their own.
Submission Guidance
Projects must be submitted via email to in a compressed file format. (.zip , .rar, .7zip , etc). This compressed file will be considered the project in its entirety and must contain all documents/files being submitted. Files contained in the archive should be common, non-proprietary formats should be used when possible; if it can’t be opened using a common consumer software consider using a different format. Each group project submission should be submitted via email by a single member of the group, with all their other respective group members CC’d.
Project deliverables and files should be created keeping common best practices in mind. Format, consistency, labels/headers/footers, naming conventions, professionalism, appropriate folders for files, etc., all contribute to a high quality product!
Plagiarism will not be tolerated. Using existing open-source templates for documents/diagrams is permissible, but any such instances must be identified/documented in the submission. If applicable, consider keeping a list of external resources used, and include it in the project submission. This may include document templates, diagram templates, or other sources of inspiration. If in doubt – cite your source.
Rubric
Each deliverable will be evaluated on a basis of meeting the deliverable requirements, project quality, and professionalism.
Please note that consistency of naming conventions, spelling, coherent writing, and formatting all factor into the “professionalism” of your project. Project feedback, after grading, will be provided relating to these factors. I reserve the right to include a personal-performance element of the grade, in the event of extreme circumstances.
The project will be graded with the following weights assigned to each deliverable.
D1 10%
D2 25%
D3 10%
D4 20%
D5 25%
D6 10%
1- Architecture Diagram (rough), Memo to the client, Requirements (CH 8)
Using identified requirements from the project scenario assigned to your team, create an abstract/top-level architecture diagram to conceptually illustrate the program (e.g. remote sites, central servers, distributed servers, n-tiers). Use a diagram software of your choice to create this. The purpose of this is to evaluate the needs of the system, conceptually illustrate to the client how the system will be outlaid. If your prompt indicates your system will be hosted in an existing data center, consider how users will access and interact with the system, or how the system will interact with other systems.
Create up to a 2pg maximum write up, in the form of an email/memo to your [Client] justifying/explaining why this architecture has been chosen, and how it meets the requirements. This write up should also discuss any identified pros and cons with this approach. If there are identified requirements that could be considered ‘major’, feel free to discuss them in the write up.
The write up should include a table of identified requirements from the program (refer to CH 8 for requirement types, examples). Groups are encouraged to take creative license with identifying/determining the requirements. Think abstractly about what requirements the program/system should satisfy, even if they are not explicitly stated in the scenario. Consider Operational, Performance, Security, and Cultural & Political requirements.
** The identified requirements for the table are NOT required to factor/influence the other deliverables for this project**
The architecture diagram and the requirements table do not count towards the 2pg maximum length of the memo, and should be included in the same document satisfying the deliverable.
2-Interface Design Prototyping and Evaluation (CH 9)
Create interface design prototypes to comprehensively illustrate the project’s forms, functions, types of information displayed/captured, and flow. You may use any number or combination of interface diagram types from the book, or other types not yet discussed in the course to accomplish this objective. The type of diagram(s) utilized should be noted for clarity’s sake.
The project is anticipated to have a significant number of screens, forms, and reports. All of these should be represented in the User Interface designs.
Groups should be mindful of user interface design principles including, but not limited to, Layout, Content Awareness, Aesthetics, Usage Level, Consistency, and Minimization of user effort. Ensure that consideration is given to input mechanisms, outputs, and navigation principles.
Groups may use more polished prototypes if they wish by using any number of available tools. However, keep in mind the purpose of abstract prototyping and the benefits they provide before skipping to more “finished” products.
Using Trello, complete a heuristic evaluation for your interface design prototypes using the following template :https://trello.com/templates/design/heuristic-evaluation-tlVIJm0l (Links to an external site.) by adding the template to a new board in your workspace shared amongst your team. This should identify and catalogue UI/UX issues you’ve identified for this deliverable. Not all items may be applicable, and you may wish to add additional evaluation items.
3-Personas & Use Scenarios (CH 9)
Create six fictional personas of the system, using the examples on pg 275 of the text for a loose reference. These personas should reflect the scenario’s identified user types. Personas do not have a specific length, but they should include sufficient information to act as an aggregate common characteristics of a particular user group. Personas should also act as a lens through which a system and its user interactions are viewed, as this can aid designers in conceptualizing how users may interact with the system, or their needs in doing so.
You may find this article helpful in understanding the value personas can add to an interface design: https://blog.adobe.com/en/publish/2017/09/29/putting-personas-to-work-in-ux-design-what-they-are-and-why-theyre-important.html#gs.y8axq3 (Links to an external site.)
Write a use scenario for each of the personas (six total use scenarios). The use scenario should go through a commonly used path in the system. The structure chart and interface prototypes should facilitate the use scenarios. Your user stories should include the Who (persona), an objective/goal or what they want to achieve, and the reason for doing so. Each user story should also include the steps or sequence of actions to accomplish that in the system.
Pg 275/276 may be a helpful reference. You may find this article helpful, as it provides a deeper look at the purpose of user stories in the SDLC: https://www.atlassian.com/agile/project-management/user-stories (Links to an external site.)
4-Program Design – Structure Charts (CH 10)
Create a structure chart for the project. It is strongly advised to review CH10 for guidance. You may find that due to the limited scope of the project, and a lack of preceding documentation (DFDs, Requirements Definitions, etc) that this deliverable may spur changes in Deliverable 2, and vice versa. This is expected, due to the iterative nature of this project.
A successful structure chart will demonstrate an understanding of modular design, and associated concepts. Coupling and Fan-In should be considered in the design and construction of your chart. The symbols listed in the textbook (pg 321) for structure chart design are optional but may help your group conceptualize the modular design. If groups choose to include them, they have that liberty. However it will not factor into my grading schema/evaluation on their own merit.
Conceptually it may be helpful to recognize that the interface design prototyping in Deliverable 2 represents what the user(s) interacts with, whereas the structure chart and breaking down the system into modules represents the “under-the-hood” or code that facilitates the system functions and processes. The ‘gas’ pedal in your car may have a simple interaction to the driver [user] “depress pedal, car moves forward. Push harder go forward quicker”, but causes a sequence of events for the car [system] involving computer calculations, valves opening, fuel injection, and other functions. It’s these underlying functions that we are trying to identify, structure, and break down into modules for the purpose of facilitating software development to achieve them.
5-Program Design – Program Specification (CH 10)
Create a program specification for each module identified in the Structure Chart from Deliverable 4. Program specifications do not have a set syntax – feel free to use a style and template of your team’s choosing. It must at minimum include program information, events, inputs/outputs, and pseudocode. Refer to the definition of pseudocode on pg 337 of the text for guidance. Pseudocode should be sufficient to function as a blueprint on how to develop the code required for that module. It is an abstraction of code written in narrative English, with the purposes of eliminating ambiguity in what the actual code for the module should do.
For the purposes of project submission, each module must have a program specification dedicated to it. All program specifications should be compiled into a single document, with each program specification clearly delineated.
The guidance and loose principles on pseudocode at the following link may be helpful for your team in maintaining consistency across your program specifications: https://towardsdatascience.com/pseudocode-101-an-introduction-to-writing-good-pseudocode-1331cb855be7
