A traditional, linear approach to software development. Consists of sequential phases, where each phase must be completed before moving onto the next. Easy to understand & manage, limited flexibility.
Waterfall processes:
RequirementAnalysis
SystemDesign
Implementation
Testing
Integration
Deployment
Maintenance
The waterfall model offers:
A clear structure and documentation
Defined deliverables
Suitable with well-defined requirements, with its disciplined approach.
However, negatives are:
lack of flexibility
limited customer involvement
sequential
inefficient resource usage
The waterfall model is more rigid and sequential, less emphasis on customer collaboration and iterative development, limited need for flexibility. Can be justified for project where disciplined approach needed, making changes later could be expensive. This may include: government contracts or safety-critical systems. If a change needs to be made within a project being developed using the waterfall model, programmers must revisit all levels between the current stage and the stage at which a change needs to be made.
SpiralModel
Riskdriven, combining the waterfall and iterative development. 4 quadrants, cyclically progressing through each. Continuous evaluation, risk management and refinement.
Determine objectives
Identify and resolve risks
Develop & test
Plan the next iteration
The spiral is good for:
riskmanagement
flexibility
incrementaldevelopment
customer involvement
But is bad for:
it's complexity
time-consuming nature
Overemphasis on risk
Less suitable for small projects: added complexity may not be justified.
Spiral model
Shares some aspects with the waterfall model, such as sequential plans
Adds some iterative development
Adds risk management for added flexibility
Rapid application development
Focusses on iterative development
Prioritises quick prototyping over risk management
More suitable for
Large, complex projects with significant risks
Projects with refinement and adaption
Projects where proactive risk management is crucial
Projects where benefits outweigh complexity
Suitable projects
Research and development projects
Mission-critical systems
RAD
Emphasises rapid prototyping, iterative development and close collaboration with end-users. Quickly deliver working software while accommodating user feedback throughout the process.
Requirement gathering
Prototyping
Iterativedevelopment
Testing and integration
Deployment
RAD is good for:
Speed - faster development and delivery
Flexible - accommodates changes and user feedback during the process.
Customer involvement - encourages close collaboration
Reduced risk via early identification.
Not good for:
Less focus on planning
Requires skilled team members
Not suitable for large-scale projects due to pace
Potential for scope creep - never-ending feedback
Agile methodology
Focuses on quick prototyping and iterative development
Flexible, adaptive
Incorporates iterative development but places greater emphasis on risk analysis and management
Agile methodologies
Share principles of iterative development and customer collaboration (different practices – extreme programming)
Agile methodology
Most suitable for small to medium sized projects
With a rapid and flexible need with high use of feedback
Agile methodology
Justified for projects where speed and adaptability are critical, benefits of user collaboration
Suitable for
Softwareprototypes
Internalbusinessapplications
Fast changing market environment
Compared to waterfall, agile methodology focuses on quickprototyping and iterative development
Extremeprogramming (XP)
Agile, emphasis on communication, collaboration, feedback and simplicity. Deliver highquality software, meetingchangingcustomer needs, promoting efficiency and adaptability + continuous improvement. Frequent releases in short development cycles.
Planning
SmallReleases
Continuousintegration
Testdrivendevelopment
Refactoring
Pairprogramming
Collectiveownership
Customercollaboration
XP is good for:
Highqualitysoftware via testing & improvement
Adaptability
Efficient development
Team morale
Drawbacks:
Requires strong communication
Notsuitable for remote teams
High initialinvestment
Limited documentation
Like other agile methodologies
XP focusses on iterative development, customer collaboration and adaptability
RAD
Focuses on rapidprototyping and iterativefeedback but not specific practices
Waterfall and spiral models
More structured and sequential compared to XP, with less emphasis on customer collaboration and iterative development
XP
Most suited to small to medium-sized projects with changing requirements
Strong emphasis on collaboration and communication
Justified for projects where high-quality software, adaptability and supportive environment are critical success factors
Could include customer-facing software, or projects with higherdegree of uncertainty
Agile
A set of principles and practices that emphasise flexibility, adaptability and closecollaboration between the development and the customer or end-users. They prioritise rapid, iterative development and the delivery of working software in small, incremental cycles. Focus on continuous improvement and prototyping, adapting to changing requirements and fostering a high degree of customer involvement throughout the development process.
Agile development methodologies
Less focus on documentation
More priority given to usersatisfaction
Different sections of software can be at differentstages of development
Non-agile (traditional):
Waterfall: linear, sequential approach to development, each phase needing to be completed to move on to the next. More rigid, less customer focussed.
Agile (or agile-inspired):
Spiral: combines elements of the waterfall model with iterative development and strong focus on risk management. Does incorporate flexibility and iterative development.
Black box testing - testing with no knowledge of the code inside and system architecture, testing to see the output given an input.
White box testing - knowledge of the code and system architecture, trying to testfaults and bugs to produce errors.
Alpha testing: carried in house, bugs pinpointed and fixed.
Beta testing: Carried out by end users after alpha, feedback from users used to form next stage of development
TELOS - Feasibility Study
Technical
Economic
Legal
Operational
Scheduling
Regardless of the problem, all good algorithms have certain key qualities which are highlighted below:
Inputs must be clearly defined - what is valid and what is invalid?
Must always produce a valid output for any defined input
Must be able to deal with invalid inputs
Must always reach a stopping condition
Must be well-documented for reference
Must be well-commented so modifications can easily be made