Scribd
Upload
42 views1 page

Oftware Evelopment Ethodologies

The document discusses different software development methodologies that a business analyst may encounter, including waterfall and agile methodologies. Waterfall involves completing each phase of the project in a linear sequence, from requirements to development to testing. While simple for small projects, waterfall is criticized for not allowing stakeholders to provide feedback until late in the process and not adapting well to changing requirements.

Uploaded by

jitendra kum
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
42 views1 page

Oftware Evelopment Ethodologies

The document discusses different software development methodologies that a business analyst may encounter, including waterfall and agile methodologies. Waterfall involves completing each phase of the project in a linear sequence, from requirements to development to testing. While simple for small projects, waterfall is criticized for not allowing stakeholders to provide feedback until late in the process and not adapting well to changing requirements.

Uploaded by

jitendra kum
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 1

SOFTWARE DEVELOPMENT METHODOLOGIES

Software development cycles characterize how an organization approaches a project. As a business


analyst, youll likely work with (or interview for jobs that use) a variety of methodologies and software
development cycles. You will want to be aware of the different methodologies, stay aware of current
literature on new and existing methodologies, and, most importantly, understand the adaptations of the
business analyst role within each methodology.

Waterfall
A waterfall methodology is exactly what it sounds like, each phase of the project (requirements, design,
development, test, and implementation) occurring in linear order and concluding with a big splash at the
end for delivery. While decidedly out of vogue, it can still be useful in very small projects.

A core argument against a waterfall methodology is that stakeholders provide the best possible
feedback on working software and by saving working software to the end of the process, a software
implemented using a waterfall methodology often fails to meet stakeholder expectations. A second
argument is based on the reality that todays organizations change and evolve rapidly. Since waterfall
methodologies support a lock down of requirements early in a project, often 6-12 months before
delivering working software, they inhibit the organization from effectively responding to change.

You might also like