0% found this document useful (0 votes)
17 views3 pages

MKT 366

The document discusses different software development methodologies including scrum, waterfall, prototyping, incremental, and agile approaches. It notes the benefits and weaknesses of each approach and how they relate to factors like team experience, organizational participation, and project size. The conclusion states that while the approaches have their own ideas, there are also relationships between them and they will continue to be used.
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
0% found this document useful (0 votes)
17 views3 pages

MKT 366

The document discusses different software development methodologies including scrum, waterfall, prototyping, incremental, and agile approaches. It notes the benefits and weaknesses of each approach and how they relate to factors like team experience, organizational participation, and project size. The conclusion states that while the approaches have their own ideas, there are also relationships between them and they will continue to be used.
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/ 3

Scrum is currently the most widely used agile process, but the scrum literature doesn’t address

the needs of safety critical systems or hardware-software integration.

Many tools exist that can be applied to agile planning. IBM Rational Team Concert provides
collaborative planning and management capabilities, including work item management and the
import of process task from the IBM process definition tool, IBM Rational Method Composer.
Team Concert integrates with other IBM and third-party tools, covering many aspects of the
development life-cycle, including requirements management, modeling and simulation, and
quality management. This allows agile planning and workflow management to be linked to
engineering processes to provide clear information for project managers and practitioners.

Engineers adopting agile may be tempted to eliminate or heavily reduce requirements


management; however, requirements are critical to successful agile delivery. A key function of
requirements is to maintain a common understanding between the customer and the project team,
which is vital for successfully planning and managing both the project and the product being
developed.

It is far more important to do what’s relevant and important for your project than to blindly
follow a generic prescription that may not completely apply in your case.

Consider these 3 dynamics:

 Team maturity and experience: Some approaches work better for less experienced teams
whereas other require expert teams.
 Organizational participation: Some frameworks are a good fit for organizations that choose to
have high organizational participation whereas others work best when teams are autonomous.
 Project size: Some processes favor minor efforts whereas others are best for large and
complex projects.

Waterfall was an early method: The main ideas behind the waterfall framework were
borrowed from engineering and applied to software development because it was clear from
the beginning that the complexity of software development could benefit from an orderly
approach. The hallmark of waterfall is a sequential development approach going through
several phases with names like requirements, design, coding, testing, integration, installation
and maintenance. This framework was useful then and is still useful today. It’s still a good
fit for less experienced teams. Waterfall projects can be easy to measure by proven matrics.
Waterfall does have its weaknesses. Project controls like reviews, meetings, documents and
reports can result in high development costs.

Prototyping Evolved as a Fix: The idea behind the prototyping approach is to create a partial
version of the software application. This technique can result in breaking the large
application into smaller parts involving one or more prototypes, with the goal of reducing
risk. This approach often utilize high user involvement. Prototyping can be mixed with
waterfall or other development methods.

3. Incremental to tackle big applications: think of the incremental framework as a sequence


of small waterfalls, each for a logical part of the application combining linear and
iterative at the same time. Why do this? Practitioners say that it lowers risk by
developing the application in smaller units like application components or subsystems.
With an incremental approach, you generally have the flexibility to handle requirements
as a part of each development segment.
There are some straightforward benefits of incremental including:
 Each mini development cycle can learn from the previous so design mistakes are
reduced.
 From the project manager’s point of view, controlling the project is less onerous.
 Project reviews by management can also be more straightforward.
One own potential downfall of incremental is that designers and developers may
be less focused on the big challenge being addressed by the overall system
because their attention is on the current component being designed or developed
and tested. Just like it’s easier to start than end a task, it’s hard to resist moving
the tough components of a application until later in the project to improve the
odds of some early success.
4. Agile: A New Direction Agile is a group of methods. Most agile methods strive to
integrate business and IT through collaboration. They combine small parts of the
application through interative and incremental developing using self-organizing and
cross functional teams. The methods used time boxes to manage time and move quickly.
Agile has many benefits like an emphasis on customer satisfaction and flexibility
regarding change. Sequent communication and interaction with customers improves the
usefulness and quality of the application. The process can be rough and tumble and
teams can be appeared as they are not organized.

Conclusion:

The development methods that have been discussed have their own main ideas yet there are
powerful relationships between them. In IBM approaches work together like waterfall and
prototyping whereas others are motivated by a strong contrast like agile as a reaction to
waterfall. Because of this vibrancy and these motivating relationships, these methods will be
used for many years to come.

You might also like