mutable-learning · gflaz · Nov 3, 2023 · Nov 2, 2023 · Nov 2, 2023 · Nov 2, 2023
diff --git a/assets/image_1698891599154_0.png b/assets/image_1698891599154_0.png
diff --git a/pages/Agile Model.md b/pages/Agile Model.md
@@ -0,0 +1,46 @@
+tags:: Software Development
+topic:: [[Development Model]]
+softdev:: Unit 3 Outcome 2
+
+-
+- offer a number of advantages over the [[Waterfall Model]], particularly for complex and changing projects
+- prefers flexibility, communication, collaboration and simplicity compared to the [[Waterfall Model]]
+- two common approaches of agile development are *Scrum* and *Kanban*
+- develop software in a series of iterations, or *sprints*, with each sprint delivering a working product increment
+- involve the customer throughout the development process
+- are adaptive to change, allowing teams to quickly adjust the product as needed
+- Agile Model advantages
+	- flexible and adaptable
+		- are designed to be flexible and adaptable
+		- makes them well-suited for complex and changing projects
+	- customer involvement
+		- involve the customer throughout the development process
+		- helps to ensure that the product meets their needs
+		- leads to increased customer satisfaction
+	- frequent delivery of working software
+		- deliver working software to the customer on a regular basis
+		- allows the customer to provide feedback and make changes early on
+		- delivers value to the customer faster
+	- improved team morale
+		- are often more enjoyable for team members
+		- allow developers to work on smaller, more manageable tasks
+		- can see their work come to fruition more quickly
+	- reduced risk
+		- help to reduce the risk of project failure by delivering working software on a regular basis
+		- allowing for changes to the project requirements early on
+- Agile Model disadvantages
+	- less predictable timelines and budgets
+		- are less predictable than the [[Waterfall Model]]
+			- as the project requirements can change throughout the development process
+		- can lead to longer timelines and higher budgets
+	- more complex to manage
+		- can be more complex to manage than [[Waterfall Model]]
+		- require more frequent communication and coordination between team members
+		- developers must be skilled at client communication as well
+	- less documentation
+		- typically produce less documentation than the [[Waterfall Model]]
+		- the focus is on delivering working software
+		- can make it more difficult to track progress and identify potential problems
+	- not suitable for all projects
+		- may not be well-suited for projects where the requirements are very well-defined or for projects where there is a high degree of regulatory oversight
+	- ![Agile Model](https://www.bluemidnight.com/wp-content/uploads/2019/04/agile-software-development-cycle-1.png)
diff --git a/pages/Analysis Actions.md b/pages/Analysis Actions.md
@@ -9,9 +9,8 @@ softdev:: Unit 3 Outcome 2
 - examine different tools to enable [[Data Collection]]
 - decide what will be and won't be a part of the [[Solution Scope]]
 - understand the difference between [[Functional Requirements]] and [[Non-functional Requirements]] that will make up the [[Solution Requirements]]
-- determine what is and is not part of the [[Solution Scope]]
 - depict interfaces between solutions, users and networks using tools such as a [[Use Case Diagram]], a [[Data Flow Diagram]] and a [[Context Diagram]]
-- select a development approach model from choices including the [[Waterfall Model]], [[Agile Model]] and [[Spiral Model]]
+- select a [[Development Model]] from choices including the [[Waterfall Model]], [[Agile Model]] and [[Spiral Model]]
 -
 - Further Research
   background-color:: purple

diff --git a/pages/Analysis Stage.md b/pages/Analysis Stage.md
@@ -10,5 +10,4 @@ softdev:: Unit 3 Outcome 2
 	- [[Solution Requirements]]
 	- [[Solution Constraints]]
 	- [[Solution Scope]]
-- update and maintain the [[Project Plan]]
--
+- update and maintain the [[Project Plan]]
diff --git a/pages/Context Diagram.md b/pages/Context Diagram.md
@@ -0,0 +1,6 @@
+tags:: Software Development
+topic:: [[Analysis Actions]]
+softdev:: Unit 3 Outcome 2
+
+-
+-
diff --git a/pages/Critical Path.md b/pages/Critical Path.md
@@ -0,0 +1,20 @@
+tags:: Software Development
+topic:: [[Project Management]]
+softdev:: Unit 3 Outcome 2
+
+-
+- is the longest sequence of tasks that must be completed on time in order for the entire project to be completed on time
+- any delays in critical tasks will delay the rest of the project
+- there is no slack time in the path
+- Slack Time
+  id:: 65444426-81cf-4884-8bee-b4afd1fe902d
+	- is the amount of time that a task can be delayed without affecting the overall project schedule
+- it is made up of tasks with [[Project Dependencies]]
+	- each task on the critical path depends on the completion of the previous task
+- is important to identify the critical path early in the project planning process
+	- helps focus your attention on the most important tasks and to develop contingency plans in case of delays
+- can change over time as tasks are completed and new information becomes available
+	- is important to monitor the critical path closely and to make adjustments to the project schedule as needed
+- may be multiple critical paths in a project
+	- especially true for complex projects with many interdependent tasks
+- the end of the critical path is the current date the project will be complete, and is the best way to estimate when the project will end at any given time
diff --git a/pages/Data Collection.md b/pages/Data Collection.md
@@ -0,0 +1,30 @@
+tags:: Software Development
+topic:: [[Analysis Stage]]
+softdev:: Unit 3 Outcome 2
+
+-
+- a crucial step in any software project
+	- it provides the foundation for understanding the client and user needs, requirements, and expectations
+- can gain insights that will help to complete the analysis, design and development of a solution
+- Methods of Data Collection
+	- [Survey]([[Data Collection/Survey]])
+	- [Interview]([[Data Collection/Interview]])
+	- [Report]([[Data Collection/Report]])
+	- [Observation]([[Data Collection/Observation]])
+- Data Collection steps
+	- identify the goals and objectives
+		- why is the data collection happening?
+			- Are you trying to understand the users' needs, identify their pain points, or get feedback on a prototype?
+		- once you know your goals, you can choose your data collection methods accordingly
+	- choose the right data collection methods
+		- best methods will depend on the goals and the type of data you need to collect
+	- target the right audience
+		- who is most likely to use the solution?
+		- what about the client?
+	- collect data from multiple sources
+		- helps to get a more complete and well-rounded view of client and user needs and requirements
+	- ask open-ended questions
+	- be objective
+		- avoid leading questions or trying to influence the respondents' answers
+	- get feedback from others
+		- share your data collection findings with other stakeholders, such as project managers, designers, and developers and the client
diff --git a/pages/Data Collection___Interview.md b/pages/Data Collection___Interview.md
@@ -0,0 +1,17 @@
+tags:: Software Development
+topic:: [[Data Collection]]
+softdev:: Unit 3 Outcome 2
+
+-
+- usually conducted face to face individually or in groups
+- Interview Advantages
+	- allow for in-depth follow-ups
+	- opportunity to ask clarifying questions based on previous responses
+	- useful to understanding feelings, attitudes and opinions of the audience
+		- which is not easy to do with surveys
+- Interview Disadvantages
+	- can take considerable time to complete
+	- may provide a limited range of information
+		- if the wrong audience is interviewed
+		- if few stakeholders are interviewed
+	- can be difficult to complete in a large project
diff --git a/pages/Data Collection___Observation.md b/pages/Data Collection___Observation.md
@@ -0,0 +1,20 @@
+tags:: Software Development
+topic:: [[Data Collection]]
+softdev:: Unit 3 Outcome 2
+
+-
+- physically viewing how a currently in-use system operates and is being used
+- typically used when designing a system to replace the current system
+- useful to help solve the current system's problems
+- extensive documentation should be taken during observations
+- Observation Advantages
+	- provides an unbiased view of current system and practices
+	- information does not rely upon being supplied by users
+	- multiple locations can be observed as needed
+	- multiple users can be observed concurrently
+- Observation Disadvantages
+	- time consuming and can be expensive
+	- may not observe all parts of the system
+	- may not occur when the system is under stress or problems are presenting
+	- users may be unwilling or nervous to contribute
+		- changes in behaviour can skew the data collected
diff --git a/pages/Data Collection___Report.md b/pages/Data Collection___Report.md
@@ -0,0 +1,22 @@
+tags:: Software Development
+topic:: [[Data Collection]]
+softdev:: Unit 3 Outcome 2
+
+-
+- usually a written document summarizing the information about the system being analysed
+	- especially common when the solution is replacing an existing system
+- commonly created by the client in preparation for the decision to implement a new solution
+- may include
+	- error reports
+	- customer complaints
+	- uptime statistics
+	- various system, performance and monitoring information
+- Report Advantages
+	- often pre-prepared and easily available
+	- inexpensive
+	- data is already formatted, collected and interpreted
+- Report Disadvantages
+	- invalid interpretations included
+	- bias or manipulation may be in the report
+	- possibly limited view of the old system
+	- may or may not contain information regarding any new system
diff --git a/pages/Data Collection___Survey.md b/pages/Data Collection___Survey.md
@@ -0,0 +1,14 @@
+tags:: Software Development
+topic:: [[Data Collection]]
+softdev:: Unit 3 Outcome 2
+
+-
+- Survey Advantages
+	- can collect data from many people quickly and efficiently
+	- easy to process if *quantitative data* is generated by the survey from *close-ended questions*
+	- can be delivered digitally
+	- can be targeted to specific people
+- Survey Disadvantages
+	- *qualitative data* resulting from *open-ended questions* can require more time and effort to analyse the results
+	- lengthy surveys can be discouraging for users and may result in fewer responses
+	- can be impersonal and general
diff --git a/pages/Data Dictionary.md b/pages/Data Dictionary.md
@@ -0,0 +1,20 @@
+tags:: Software Development
+topic:: [[Solution Design]]
+softdev:: Unit 3 Outcome 2
+
+-
+- used to design the storage of software elements including
+	- [[Processing Feature/Variable]]
+	- [[Data Structure]]
+	- objects such as GUI elements
+- should list
+	- name
+	- [[Data Type]] or [[Data Structure]]
+	- may also include purpose, source, size, description, formatting and validation
+- useful when code needs to be modified and variable details are not easily understandable from the code alone
+- ![Data Dictionary example - Wikipedia](https://upload.wikimedia.org/wikipedia/commons/thumb/4/45/Data_dictionary.png/450px-Data_dictionary.png){:height 320, :width 678}
+-
+- Further Research
+  background-color:: purple
+	- Read
+		- [Data dictionary - Wikipedia](https://en.wikipedia.org/wiki/Data_dictionary)
diff --git a/pages/Data Flow Diagram.md b/pages/Data Flow Diagram.md
@@ -0,0 +1,6 @@
+tags:: Software Development
+topic:: [[Analysis Actions]]
+softdev:: Unit 3 Outcome 2
+
+-
+-
diff --git a/pages/Development Model.md b/pages/Development Model.md
@@ -0,0 +1,12 @@
+tags:: Software Development
+topic:: [[Analysis Actions]]
+softdev:: Unit 3 Outcome 2
+
+-
+- there are many different ways to approach a software development project
+- models are designed to provide some structure to the process and help ensure a quality end product
+- these are known as *Software Development Life Cycle (SDLC)* models
+- SDLC Models
+	- [[Waterfall Model]]
+	- [[Agile Model]]
+	- [[Spiral Model]]
diff --git a/pages/Functional Requirements.md b/pages/Functional Requirements.md
@@ -0,0 +1,15 @@
+tags:: Software Development
+topic:: [[Solution Requirements]] 
+softdev:: Unit 3 Outcome 2
+
+-
+- is a statement that describes what the software must do
+	- is a specific description of the desired behaviour of the software
+	- is usually expressed in terms of the inputs and outputs of the system
+		- dot points are often included to further clarify and add detail
+		- if user interaction is part of the requirement a [Use Case]([[Use Case Diagram]]) may be included
+- are typically written in a clear and concise manner, and they should be unambiguous and measurable
+- are important because they help to ensure that the software meets the needs of its users and stakeholders
+	- carefully defining and documenting functional requirements helps to avoid surprises and ensure that the software is working as intended
+- are typically gathered from a variety of sources, including users, stakeholders, and analysts
+	- should be reviewed and refined by the software development team to ensure that they are complete, consistent, and feasible
diff --git a/pages/Gantt Chart.md b/pages/Gantt Chart.md
@@ -0,0 +1,36 @@
+tags:: Software Development
+topic:: [[Project Management]]
+softdev:: Unit 3 Outcome 2
+
+-
+- a graphical representation of the scheduling of the [[Project Plan]]
+- steps to create a Gantt Chart
+	- know the important project details
+		- budget
+		- scope
+		- deadlines
+	- identify all the [[Project Tasks]]
+		- break complex tasks up into subtasks, and even further into more levels if needed
+	- identify and list all the ((6543174f-65ba-433a-9085-39781bad1d0e))
+	- determine all the [[Project Dependencies]] for the set of tasks that make up the project
+		- shown with lines between tasks and an arrow indicating the relationship
+	- add tasks in sequence to the chart
+	- set the tasks properties
+		- duration
+		- resources
+		- dependencies
+	- create [[Project Milestones]] when significant achievements will be reached
+		- shown as a diamond with no duration
+	- document important information in the chart with notes and annotations
+- the [[Critical Path]] and any ((65444426-81cf-4884-8bee-b4afd1fe902d)) should be easily visible in the chart once all tasks are added and set up correctly
+- ![Gantt Chart example](https://i1.wp.com/www.proprojectmanager.com/wp-content/uploads/2015/07/GANTT.jpg)
+-
+- Further Research
+  background-color:: purple
+	- Read
+		- [Gantt chart - Wikipedia](https://en.wikipedia.org/wiki/Gantt_chart)
+		- [GanttProject - Free Project Management Application](https://www.ganttproject.biz/)
+	- Watch
+		- {{video https://www.youtube.com/watch?v=qp0VH_wL7Ws}}
+		- {{video https://www.youtube.com/watch?v=5FukJpd_VNs}}
+		-
diff --git a/pages/Mock-up.md b/pages/Mock-up.md
@@ -0,0 +1,28 @@
+tags:: Software Development
+topic:: [[Solution Design]]
+softdev:: Unit 3 Outcome 2
+
+-
+- if the software has an interface for users to interact with this will help with its design
+- shows how some part of the interface with look to a user
+	- could be a report or output
+- typically includes
+	- the position and sizes of controls such as buttons and scroll bars
+	- the positions, sizes, colours and styles of text such as headings and labels
+	- menus, status bars and scroll bars
+	- borders, frames, lines, shapes, images, decoration and colour schemes
+	- vertical and horizontal object alignments
+	- the contents of headers and footers
+- annotations are also vital to allow developers to understand details about the mockup's elements that are not easily displayed
+	- how a button changes when the mouse hovers over it
+	- an animation effect
+	- what happens when a button is clicked
+-
+- Further Research
+  background-color:: purple
+	- Read
+		- [Mockup - Wikipedia](https://en.wikipedia.org/wiki/Mockup#Software_engineering)
+		- [UI Mockup Generator - Create Mockups Online | Lucidchart](https://www.lucidchart.com/pages/examples/mockup-generator)
+		- [Free Mockup Generator - Create Mockups Online | Canva](https://www.canva.com/create/mockup-generator/)
+	- Watch
+		- {{video https://www.youtube.com/watch?v=5IanQIwhA4E&pp=ygUWc29mdHdhcmUgZGVzaWduIG1vY2t1cA%3D%3D}}
diff --git a/pages/Non-functional Requirements.md b/pages/Non-functional Requirements.md
@@ -0,0 +1,36 @@
+tags:: Software Development
+topic:: [[Solution Requirements]] 
+softdev:: Unit 3 Outcome 2
+
+-
+- are what the user or client would like the solution to have that don't affect what it does
+- generally relate to the *quality* of the solution
+	- often opinionated requirements rather than specific targets that must be present
+- must be measurable for testable
+- usually developed in conjunction with client input
+- often closely associated with [[Solution Constraints]]
+- Non-functional Requirement categories
+	- Usability
+		- how easy it is to learn and use the solution
+		- clarity of the user interface
+		- how intuitive it is you use the system (affordance)
+		- measurable in terms of user satisfaction
+	- Reliability
+		- can it be depended on to function as designed
+		- resistance to failure
+		- measured as *uptime*
+	- Portability
+		- how easily it can be used in different environments
+		- ease of installation and moving user data between devices
+		- ability to use the system on multiple OS/device types
+		- use in multiple languages
+	- Robustness
+		- how well the system responds to unexpected errors when in use
+		- error handling techniques
+		- relates closely to [[Validation Techniques]] used
+		- prevention of user error
+		- measured in terms of number of failures/crashes
+	- Maintainability
+		- how easy it is to keep the software running after it is in use
+			- ease of fixing, modifying, installing or changing the software once in use
+		- measured by staff hours needed to keep the software running
diff --git a/pages/Object Descriptions.md b/pages/Object Descriptions.md
@@ -0,0 +1,20 @@
+tags:: Software Development
+topic:: [[Solution Design]]
+softdev:: Unit 3 Outcome 2
+
+-
+- a way of documenting a [[Data Structure/Class]] or an object such as a user interface element
+- similar to a [[Data Dictionary]] but specific to one object
+- describes the structure, behaviour, and relationships of an object in a software system
+- very useful if the object is modified at a later data
+- describes
+	- class variables or object properties
+	- object methods and events
+	- any other important details
+- typically written in natural language, but can also be written in UML
+- can be used to describe simple and complex objects
+- an object description for a 'Car' object in a racing sim might include information about
+	- the car's properties
+		- make, model, year, color, and engine size
+	- also include information about the car's methods
+		- drive(), brake(), and turn()