software development methodologies for the computer science ia (2014 syllabus)

9
Software Development Methodologies For the Computer Science IA (2014 syllabus)

Upload: darleen-merritt

Post on 23-Dec-2015

213 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Software Development Methodologies For the Computer Science IA (2014 syllabus)

Software Development MethodologiesFor the Computer Science IA (2014 syllabus)

Page 2: Software Development Methodologies For the Computer Science IA (2014 syllabus)

Rationale

The guidelines for the IA state that you have to justify you choice of methodology

It's got to be a good idea to have something to say about what you've done and why you've done it that way

The aim of this document is to give you what you need to add a short paragraph to your Solution Overview (Criterion B) section that meets the requirement

Page 3: Software Development Methodologies For the Computer Science IA (2014 syllabus)

The Principal Methodologies

Waterfall development Prototyping Incremental development Spiral development Rapid application development Other practices

Page 4: Software Development Methodologies For the Computer Science IA (2014 syllabus)

Waterfall development

Emphasis is on planning, time schedules, target dates, budgets and implementation of an entire system at one time

Big design up front A bit old-fashioned e.g. http://en.wikipedia.org/wiki/Structured_systems_analysis_and_design_method

Page 5: Software Development Methodologies For the Computer Science IA (2014 syllabus)

Prototyping

Reduce risk by breaking project into smaller segments

Change accommodated more easily User is involved throughout the

development process, which increases the likelihood of user acceptance of the final implementation

Small-scale mock-ups of the system Evolution from prototype to working

system

Page 6: Software Development Methodologies For the Computer Science IA (2014 syllabus)

Incremental/Spiral Development

Mixture of Waterfall and Prototyping

Project broken down into smaller parts

Mini-waterfalls for each part Requirements and design

done like Waterfall, implementation done by Prototyping

Page 7: Software Development Methodologies For the Computer Science IA (2014 syllabus)

Rapid Application Development (RAD)

Less emphasis on planning More emphasis on development Cycles of development, user

reaction, development, etc Incorporates prototyping Flexibilityhttp://en.wikipedia.org/wiki/Rapid_application_development

Page 8: Software Development Methodologies For the Computer Science IA (2014 syllabus)

Top-down versus bottom-up

Top-down approaches emphasize planning and a complete understanding of the system. It is inherent that no coding can begin until a sufficient level of detail has been reached in the design of at least some part of the system.

In a bottom-up approach, the individual base elements of the system are first specified in great detail. These elements are then linked together to form larger subsystems, which then in turn are linked, sometimes in many levels, until a complete top-level system is formed. Related to object-oriented design.

Page 9: Software Development Methodologies For the Computer Science IA (2014 syllabus)

What to put in your IA

I can't be 100% prescriptive.

One short paragraph.

Don't all put the same thing.

Methodologies mentioned in this document are not mutually exclusive so you might use elements of several.

Certainly include the words "design methodology", maybe even as a subheading

You are all using Java so your approach is inherently object-oriented. What are the advantages of this?

You are all surely building at least one prototype? More?

Are there any functions/routines that you knew you would need and chould develop even though you didn't fully know how the software would work in the end? (bottom-up)

Did you spec the system down to the last variable before you started to code? (top-down)

How much was the client involved in the design/development process?

How was your choice of approach affected by your client's: availability

technical knowledge

clarity of requirements

etc