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

- 

- select a [[Development Model]] from choices including the [[Waterfall Model]], [[Agile Model]] and [[Spiral Model]]

- update and maintain the [[Project Plan]]

tags:: Software Development

topic:: [[Analysis Actions]]

softdev:: Unit 3 Outcome 2

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

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

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

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

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