CIST8950
This repository services the UNO Cybersecurity capstone (CYBR 4580/8950)
CYBR8950 Project Milestone 1: Requirements analysis and planning (Project Proposal Stage)
Submit a GitHub repo link to canvas Add Dr. Hale as a collaborator on your GitHub Repo
Overview
This project milestone tasks you with identifying project requirements, analyzing them to determine needed resources (technology and skillsets), preparing a project management plan, and packaging all of this as a project proposal. Overall, this means you will prepare a series of project management and design artifacts. Towards this goal, you will be required to submit the following by the due date:
- Executive Project Summary - What are you doing and why?
- Goals and Objectives
- Merit of the Project
- Proposed project timeline - When will you do it?
- Define the tasks and expected time to completion
- Create and submit a gantt chart or other planning chart
- Project-oriented risk list - What could go wrong in the project and why?
- Project Methodology - What has been done in the literature and what is your technical plan?
- Resources/Technology needed - What do you need to be successful?
- First Sprint Plan - Create the first plan on GitHub Kanban
- Note about Teamwork and Group projects
Using GitHub and Markdown
For this and future projects you will submit your milestone work using GitHub (only adding the link to Canvas).
Executive Project Summary
An executive summary should be evocative. It should capture a reader and make them want to be a part of your idea. In this milestone you will write an executive summary that defines the goals and objectives of your project in language that is easily readable and mental-image evoking. I (or anyone else) should be able to read your executive summary and instantly know a) what you are doing and b) why it is important. Executive summaries should be exciting and interesting. It is the first (and likely the only) chance for you to engage your reader and, in a real world setting, would determine if your product gets funded. An executive summary does not need technical detail to describe interesting functionality. You should mention your product by name without using phrases such as “the class”, “the instructor”, “project 2” etc.
Submission materials
You should submit a summary document (in markdown format) on your GitHub project repo. Call the file README.md and place it in the top-level directory of your GitHub project.
It should contain the following:
- A problem statement identifying relevant issues related to your bid. The problem statement might also discuss why these issues are a problematic for society, a particular industry/sector/company/agency, or a specific technology(ies).
- Project goals and objectives in a numbered or bulleted list that you propose to undertake to address the identified problem. Clearly identify what you are doing at a high level with minimal technical detail.
- The merit of accomplishing the project goals and objectives in terms of how it helps end users, society, or particular industries/sectors/companies/agencies.
Grading criteria
Your summaries will be graded as follows following:
| Meets expectations (9-10) | Some Issues (6-8) | Does not meet expectations (0-5) | |
|---|---|---|---|
| Problem statement | Clearly identifies the context of the problem addressed by your project. Answers the question - Why is this an area of interest? | Problem context not clearly identified, leaves reader wondering why the project is necessary. | Problem context unclear or not identified. |
| Project goals | Project goals are clear, concise, and in a bulleted list. Efforts are clearly tied to addressing the identified problem. Goals are stated at a high level and are free of technical jargon or unnecessary detail. | Goals are not as clear, ‘in the weeds,’ or not directly applicable to the problem. | No goals are identified or there are severe clarity issues. |
| Project Merit | The benefits for pursing the project are clear and tied to addressing the identified problem(s). End user, societal, and industrial benefits are stated - if relevant. | Benefits and merits of the proposed work are muddled or not tied to the problem statement. | Merits are difficult to identify or missing entirely. |
| Length | Summary is of reasonable length (no longer than 1 page, not too short) | Summary is slightly too short or too long | Summary is extremely short or long. |
| Grammar, spelling, syntax | Summary is evocative and free of grammar, spelling, or syntax issues. | Summary contains a few syntax, grammar, or spelling issues. | Summary is difficult to read due to glaring grammar, syntax, or spelling issues |
| Use of markdown | Summary should render as the project homepage on your GitHub repo. It should following markdown conventions. | Doesn’t perfectly follow markdown syntax or isn’t rendered on the repo home page correctly. | Doesn’t use markdown or isn’t displayed in the repo. |
60 points
Proposed project timeline
An important part of project planning is identifying tasks to be completed to address project goals and arranging those tasks in such a way that they can be completed within a (typically) fixed interval of time. In this class, that interval is the length of the semester. For milestone one, prepare an overall project timeline that identifies large tasks to be completed, estimates time of completion, and arranges those tasks chronologically over the project lifespan.
Submission materials
You should create a project (Kanban) board on GitHub and the create task cards that identify major tasks that span the rest of the semester. You can read more about the GitHub Project feature here: https://docs.github.com/en/github/managing-your-work-on-github/about-project-boards
Grading Criteria
Your gantt chart will be graded as follows:
| Meets expectations (9-10) | Some Issues (6-8) | Does not meet expectations (0-5) | |
|---|---|---|---|
| Identifies major tasks | Major tasks addressing your objectives (from the executive summary) are identified by name. Set of tasks is appropriate to the objectives and time frame. | The set of tasks is not scoped well (too much or too little) or they do not seem to address the objectives well. | No or few tasks are identified - or they are extremely poorly scoped. |
| Chronologically arranged | Tasks are intelligently arrayed by time into milestones. | Tasks are poorly arranged. | Tasks are extremely poorly or not arranged in time. |
| Achievable | Timeline is expectedly achievable given time frame and team size. | Timeline/task achievability is questionable. | Timeline is completely unrealistic. |
| GitHub Usage | Your tasks are created using the GitHub project interface | N/A | Your tasks are not on GitHub Projects |
40 points
Risk list
As you will probably discover, there are many things that can go wrong when working on a project. Issues with skillsets, technology, team member availability, etc, may arise as the project goes forward. As we discussed in class, there are three options available to deal with project management risks: monitor it (Watch it), mitigate it (do something about it), accept it (give up). For milestone one, you should identify the major sources of risk and what you plan to do about them. Prepare a risk list and rank them by risk level using the standard formula, i.e. impact x likelihood, to describe the top 5 risks that might affect your team’s ability to pull off the tasks identified in your timeline and dictated by your objectives.
Submission materials
You should prepare a risk list table and add it to your README.md file in your GitHub project repo, beneath your Gantt chart. The table should use markdown syntax such as:
|Risk name (value) | Impact | Likelihood | Description |
|-------------------|------------|------------|-------------|
|Some risk (40) | 8 | 5 | Some description |
to generate github-displayable tables such as:
| Risk name | Impact | Likelihood | Description |
|---|---|---|---|
| Some risk (40) | 8 | 5 | Some description |
Grading Criteria
Your risk list will be graded as follows:
| Meets expectations (9-10) | Some Issues (6-8) | Does not meet expectations (0-5) | |
|---|---|---|---|
| Impact | Each risk has an identified impact factor. Factor should be based on how significant the event would be towards the disruption of your project activities. | Some factors missing or unreasonable. | No factors identified or factors are completely unreasonable |
| Likelihood | Each risk has an identified likelihood factor. Factor is reasonable. | Some factors missing or unreasonable | No factors identified or factors are completely unreasonable |
| Name and description | Risk name and description are appropriate and understandable. | Some risks are unclear. | Most or all risk are unclearly described or descriptions are missing. |
| Coverage and relevance | Identified risks are relevant to the project and cover obvious potential problem areas. | Some coverage or relevance is missing. | Risks do not address obvious potential problem areas or aren’t relevant. |
40 points
Project Methodology
Methodology is extremely important for conducting a successful project. While I am always a fan of “winging it” when it comes to day-to-day life - winging it is not an option for being successful on a team. Hence, in this class you will be required to develop a technical plan (AKA Methodology) to succeed. Your methodology should be grounded in scientific method and best practice. It should be based on the literature in the area you are working on and should use well-tested methods when possible.
Requirements are extremely important for conducting a successful project - of either the creative or assessment-oriented varieties. Collecting requirements about an application means understand what your end user (or what the end user of a product you are assessing) is going to do with the product. To understand requirements we often define user stories and use cases to encapsulate and represent behavior.
Submission materials
Literature Review
For milestone 1, you should prepare a literature review document that surveys the various research and development work in your project area. Your literature review should identify important keywords, relevant research papers, and the state of the art in your area.
Technical Plan
Once you have examined the relevant literature, you should prepare a technical plan that outlines and defines your methodology. Important consideration should be made to ensure that your methodology uses the literature to the best extent possible. Your technical plan should provide a detailed description of exactly what and how you will do what you plan to do.
Any data collection, testing/development methods, architectures, and data analysis techniques that you wish to use should all be included in your technical plan.
Grading Criteria
Your methodology (Lit review and Technical Plan) will be graded as follows.
Initial Lit review
| Meets expectations (27-30) | Some Issues (20-26) | Does not meet expectations (0-19) | |
|---|---|---|---|
| Coverage | The literature review includes a range of topics and research relevant to the problem. | There are some areas that are not surveyed in the literature | The literature review is incomplete with respect to coverage |
| Depth | Important sources that stand out in the literature are reviewed and discussed in detail. It is clear that the team has properly reviewed the cited works. | Some important references are not properly discussed in-depth. Questions exist as to the type or application of the cited works. | Many ill-defined or poorly sourced references. |
| Use of structured Abstracts | The team uses structured abstract formats for their annotated bibliography. The structured abstracts are informative and useful for later. | The format is used, but annotations are not informative. | The format is not used or the annotations are poor and uninformative. |
90 points
Initial Technical Plan
| Meets expectations (27-30) | Some Issues (20-26) | Does not meet expectations (0-19) | |
|---|---|---|---|
| Coverage | The technical plan overviews all of the areas required to be successful in the project. | Some work is not considered, but will be required. | Many missing areas of work. |
| Depth | The technical plan contains sufficient detail to understand and define exactly what will be done in the project. | Some technical details are missing or unclear. | Many technical details are missing or unclear. |
| Soundness | The technical plan is rooted in scientific method and the plan is well designed. | Some methodological issues may exist, but by and large the plan is sound. | Many issues exist in the design of the plan. |
| Scope | The technical plan is properly scoped for the duration of the class. | There are some scoping issues (too much/too little work). | Many scoping issues exist and/or the plan is unachievable. |
120 points
Resources Needed
Every team needs something to pull off their project. Clearly identify the technologies and products involved in your project.
Submission materials
Under your requirements section in the README.md file in your GitHub repo, clearly identify the technologies, products, and languages involved in your project. Include a table that identifies which team member will investigate each needed resource. Also include a column indicating whether or not material resources are needed from Dr. Hale.
Use the following table structure.
|Resource | Dr. Hale needed? | Investigating Team member | Description |
|-------------------|---------|---------------------------|-------------|
|Some resource| No | Bob | Some description |
|e.g. PLC unit | Yes | Gary | A programmable logic controller from Siemens for investigation.|
This will generate a table of the form:
| Resource | Dr. Hale needed? | Investigating Team member | Description |
|---|---|---|---|
| Some resource | No | Bob | Some description |
| e.g. PLC unit | Yes | Gary | A programmable logic controller from Siemens for investigation. |
Grading Criteria
You will be graded as follows:
| Meets expectations (9-10) | Some Issues (6-8) | Does not meet expectations (0-5) | |
|---|---|---|---|
| Coverage | A reasonable set of resources are listed that are appropriate to your project. | Some missing critical resources that are needed but not listed. | Many critical resources are needed, but not listed. |
| Conforms to structure | Entries follow tabular format specified. Each resource has an assigned team member investigating it. | Some issues following structure. | Table not formatted or many issues. |
20 points
Project management Organization
This milestone represents the first step forward in your capstone project. We will use Sprint / Agile-like methods to track your progress and organize your project management artifacts. In particular, you will use GitHub Issues to do this.
Submission materials
This part of the milestone is strictly captured by the GitHub Issue tracker and its linkages to the Project Kanban board. For this proposal milestone, you should create issues for the first tasks you are investigating. Don’t be afraid to break complex tasks down into sub tasks. Refer to the issue tracking tutorial for more information about how to do this.
Grading Criteria
You will be graded as follows:
| Meets expectations (9-10) | Some Issues (6-8) | Does not meet expectations (0-5) | |
|---|---|---|---|
| Coverage | Relevant issues are created in the issue tracker. | Issues do not capture initial tasking. | Few or no issues are present. |
| Labeling and assignment | Issues use GitHub tags and are assigned to a team member | Some issues are labeled and assigned. | Few or no labels and assignments are used. |
20 points
Presentation
You will be expected to present your Milestone 1 proposal to the class. It is important that you use this time to inform your classmates and get feedback. Things to be considered are 1) conveying a sense of interest and excitement about your project, 2) soliciting feedback from peers that might be useful for development or refinement of the project, and 3) presenting your methodology and scope to get recommendations from peers and the instructor.
Submission Materials
You will record your presentation as a video using VidGrid. Post the video to the canvas submission page AND in the slack #general chat. Also submit your slides on canvas.
Grading Criteria
You will be graded by a presentation rubric on canvas.
Total 70 points.
Teamwork
Lastly, it is important that you realize you are working on a TEAM (except for the few of you that are soloing). I will say now, that your grade is dependent on your participation. I will not allow individuals to sluff off on a team. Your grade is therefore based partly on a participation factor. Essentially if you don’t participate (and trust me We will know) - you will not get all of the team points on your project grade.
Your final grade on the milestone is computed as follows: team_grade * participation_factor = individual_grade
participation_factor is a number from 0 to 1 that is based on four measured participation factors:
- Contribution to the GitHub repo
- Activity in the slack channel for your project
- Activity on GitHub Projects
- In-class participation and participation in team meetings.
- Team evaluations
If you do your work and participate, you will get the full team points (participation_factor=1), if you don’t do anything, you will get 0% of the team points, if you aren’t doing enough you will suffer a correspondingly appropriate penalty to your grade. This means that you can FAIL even if your team succeeds - so don’t sluff off and expect the team to carry you.
License
CYBER4580 and related works by Matt Hale are licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.