1.2.3 software development

Software/Systems Development Life Cycle

• number of distinct phases programmers work through when developing a solution to a problem for a computer system

-Feasibility (is problem solvable) - Requirements (work out what solution needs to do) - Analysis + Design (work out how solution needs to do it - Implementation (code solution) - Testing (check it works) - Deployment (install in target environment) - Evaluation (check with user that solution is complete) -Maintenance (ensuring it continues to function. improve by patches/updates)

• arrangement of distinct phases and how programmers move from one phase to another (forwards or backwards)

• Waterfall • Rapid Application Development • Spiral • Agile • Extreme Programming

• each phase has a well-defined start and end with identifiable deliverables

• clear responsibilities at each stage • simplicity = easy to manage • clear deliverables • possible for different parts of team to be geographically remote

• if requirements change part way through project, previous stages must be repeated delaying project • caries risk • end user doesnt see project until end

• large projects with static, well understood requirements and one carrying little risk • not suitable for complex projects

• allows you to move back to previous phases as well as forwards (reflects fact that developers often have to rework earlier stages in light of knowledge gained as development progresses)

• involves producing successive prototypes of software until a final version is produced and approved

• increasingly refined prototypes made with reduced functionality which are designed, coded + tested then evaluated with end user until final working solution is achieved.

• further improvements needed –> starts new iteration (analysis, design, coding, testing, evaluation)

• continuous feedback from client means solution likely to have good usability • quick iteration times reduce development time and speed up delivery • requirements don’t need to be entirely clear • focus groups involving user can be used to gather requirements without need for full formal requirement document upfront • can be confident end product meets users needs

• little attention paid to program efficiency due to focus on usability • doesnt scale well • can overrun initial budgets due to being agile approach • regular contact with client must be maintained

• smaller projects where there is ready access to an end user • projects where initial requirements not fully understood as iterative nature prevents side tracking of development

• risk-driven development methodology • acts as more of a guide for development teams allowing them to adopt elements of one or more other methodologies like waterfall or RAD

• quadrant 1: Objectives and requirements determined • quadrant 2: risks and issues. A prototype is then developed • quadrant 3: this prototype tested. • After this the project is either complete or if the user wants more the final quadrant works on what will go into the next spiral.

• false, spiral model order is dependent on project and its unique risks

• prioritises risk management and can handle changes in requirements • suitable for high risk applications

• if risk analysis done badly, project will suffer • complex nature of risk analysis increases costs (risk management is a highly specialised skill)

• large, high-risk projects without tight time constraints and one where user doesnt fully understand their requirements upfront

• group of methodologies which focus on idea that requirements will shift and change during development - this can only be dealt with by producing software in an iterative way • they’re a more refined form of older concepts behind RAD

• building each iteration in sprint cycles