16/02/2016
Then best way to understand what is the ‘Waterfall’ is by definition from Phillips Kruchten:
‘The traditional mindset of developing software is usually what is called the Waterfall model. Using the Waterfall model a project should not move from one phase to the next until the preceding phase is completely fulfilled and perfected. It is not possible to jump back to an earlier concluded phase.
This development model is displayed in the figure below. One problem with this approach is that risk is pushed back into the development process and can, if the software is of any significant size, cause problems later in the process. This can lead to increased cost in the project or/and may result in project termination.’
Planning, designing, and architecture is more straightforward since the customer and the developers agree on what will be delivered early in the life cycle. Since the full scope of work is known, progress is also more easily measured.
Depending on the phase of the project all team members do not need to be locked down in the project.
As an example business analysts (BAs) can proceed work on other parts, or other projects entirely, after requirements are written and vice versa, developers do not need to be involved before the BAs actually know what needs to be delivered.
Based on requirements from BAs, testers can prepare test scripts while developers are coding along etc.
After the requirements stage, there does not exist call for customer continual presence so they can re-focus on their own business. The customer predominantly has to participate only for status reviews, approvals etc.
If multiple systems/components/software packages have to have to be unified and/or launched at the same time (internal and/or external) an early design is usually required. In this case, it is perfectly suited to the staged approach of Waterfall.
Architecture, a trade often is forgotten or neglected in modern software development, can also be designed better for scalability, overall coherence, and completeness since there is a more thorough understanding of all parts of the entire system. The source code does not need to be rewritten over and over again, which sometimes can be the case in Scrum and which sometimes results in a piecemeal system.
Project resources are not as severe since planning and documentation then been done, so when a developer give up, it is easy for a newly named resource to fill the position and get up to speed quickly and follow the plan.
As the Waterfall method requires planning in advance, software can be delivered promptly after development. Assessment of timetables and budgets can be done flawlessly, which obviously influence customers’ experience.
Gathering and documenting requirements so the customer understands what they mean is very difficult. Customers are usually overwhelmed by technicalities, and specific details must be contributed early in the project before progress can be made. Clients are often incapable envision the end product from a requirements document. Wireframes and mockups will help, but most end users have difficulty understanding these elements in enough detail to clearly envision the final product application.
Clients are often incapable envision the end product from a requirements document. Wireframes and mockups will help, but most end users have difficulty understanding these elements in enough detail to clearly envision the final product application.
This problem means that customer might be dissatisfied with their delivered product once it is complete. As all deliverables are based upon documented requirements, a customer may not see what will be delivered until large parts of the project are finished. At that point in time, changes are difficult and costly.
Agile software development methodology is a process for developing software (like other software development methodologies – Waterfall model, V-Model, Iterative model etc.) However, Agile methodology differs significantly from other methodologies. In English, agile by Merriam-Webster means:
marked by ready ability to move with quick easy grace
having a quick resourceful and adaptable character
these are the two key aspects of Agile software development : move swiftly and implement the change quickly.
Agile development methodology develops circumstances to evaluate the path of a project during the whole development cycle. This is achieved through regular cadences of work, known as sprints or iterations, at the end of which teams must present a potentially shippable product increment. By focusing on the repetition of abbreviated work cycles as well as the functional product they yield, agile methodology is described as “iterative” and “incremental.”
In waterfall, development teams only have one chance to get each aspect of a project right. In an agile methodology every stage of development lifecycle (requriments analysis, design, testing, etc) is recurringly revisited throughout the whole lifecycle. When a team make a stop and reconsider the path of a project every fourteen days, there’s always time to change it to the other way.
The results of this “inspect-and-adapt” approach to development greatly reduce both development costs and time to market. Because teams can develop software at the same time they’re gathering requirements, the phenomenon is known as “analysis paralysis” is less likely to impede a team from making progress.
Because an Agile team’s task cycle is restricted to fourteen days, it gives stakeholders persistent freedom to fine-tune releases for success in the end.
Agile development methodology helps companies build the right product. Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to continuously re-plan their release to optimize its value throughout development, allowing them to be as competitive as possible in the marketplace.
Development applying an agile methodology keeps product’s crucial market relevance and ensures a team’s work doesn’t wind up on a shelf, never released.
In Agile team, all developers and testers closely collaborate with each other to deliver business value. Every tester has to have capable of multi usable skills on board to become a cross function team member.
Agile testers require skills in developing scripts for automation of test cases, test-driven development, and acceptance tests, manual testing both white box and black box testing methods.
Agile methods demand better teamwork, active communication, and cooperation between team members and external service providers as well as stakeholders who can directly or indirectly lead the product development.
07/08/2018
