Question

1. Study the research papers and write a report on the following Agile Software Development Methods (ASDMs)

1. Adaptive Software Development (ASD)
2. Dynamic System Development Method (DSDM)
3. Crystal
4. Feature Driven Development (FDD)

2. Conduct a comparative analysis between Traditional Software Development Methods (TSDMs) and Agile Software Development Methods (ASDMs)
3. Attach the Plagiarism report for your document

Answer 1

1. Adaptive Software Development (ASD

Adaptive Software Development is a move towards adaptive practices, leaving the deterministic practices in the context of complex systems and complex environments. Adaptive Software Development focuses on collaboration and learning as a technique to build complex systems. It is evolved from the best practices of Rapid Application Development (RAD) and Evolutionary Life Cycles.

In literary terms, the word “agile” means someone who can move quickly and easily or someone who can think and act quickly and clearly. In business, “agile” is used for describing ways of planning and doing work wherein it is understood that making changes as needed is an important part of the job. Business “agility” means that a company is always in a position to take account of the market changes.

In software development, the term “agile” is adapted to mean “the ability to respond to changes − changes from Requirements, Technology and People.”

The Agile Manifesto was published by a team of software developers in 2001, highlighting the importance of the development team, accommodating changing requirements and customer involvement.We are uncovering better ways of developing software by doing it and helping others do it.

Adaptive Software Development is a move towards adaptive practices, leaving the deterministic practices in the context of complex systems and complex environments. Adaptive Software Development focuses on collaboration and learning as a technique to build complex systems. It is evolved from the best practices of Rapid Application Development (RAD) and Evolutionary Life Cycles. Adaptive Software Development was then extended to include adaptive approaches for the management, with speculation replacing Planning.

Adaptive Software Development has evolved from RAD practices. The team aspects also were added to these practices. Companies from New Zealand to Canada, for a wide range of project and product types, have used adaptive Software Development.

Jim Highsmith published Adaptive Software Development in 2000.

Adaptive Software Development practices provide ability to accommodate change and are adaptable in turbulent environments with products evolving with little planning and learning.

Adaptive Software Development is cyclical like the Evolutionary model, with the phase names reflecting the unpredictability in the complex systems. The phases in the Adaptive development life cycle are −

• Speculate
• Collaborate
• Learn

These three phases reflect the dynamic nature of Adaptive Software Development. The Adaptive Development explicitly replaces Determinism with Emergence. It goes beyond a mere change in lifecycle to a deeper change in management style. Adaptive Software Development has a dynamic Speculate-Collaborate-Learn Lifecycle.

The Adaptive Software Development Lifecycle focuses on results, not tasks, and the results are identified as application features.

2. Dynamic System Development Method (DSDM)

DSDM is an Agile method that focuses on the full project lifecycle, DSDM (formally known as Dynamic System Development Method) was created in 1994, after project managers using RAD (Rapid Application Development) sought more governance and discipline to this new iterative way of working.

DSDM’s success is due to the philosophy “that any project must be aligned to clearly defined strategic goals and focus upon early delivery of real benefits to the business.” Supporting this philosophy with the eight principles allows teams to maintain focus and achieve project goals.

The eight Principles of DSDM are:

1. Focus on the business need
2. Deliver on time
3. Collaborate
4. Never compromise quality
5. Build incrementally from firm foundations
6. Develop iteratively
7. Communicate continuously and clearly
8. Demonstrate control

DSDM is vendor-independent, covers the entire lifecycle of a project and provides best practice guidance for on-time, in-budget delivery of projects, with proven scalability to address projects of all sizes and for any business sector.

DSDM advocates the use of several proven practices, including:

• Facilitated Workshops
• Modelling and Iterative Development
• MoSCoW Prioritisation
• Time boxing

There are some roles introduced within DSDM environment. It is important that the project members need to be appointed to different roles before they commence the project. Each role has its own responsibility. The roles are:

• Executive Sponsor So called the “Project Champion”. An important role from the user organisation who has the ability and responsibility to commit appropriate funds and resources. This role has an ultimate power to make decisions.
• Visionary The one who has the responsibility to initialise the project by ensuring that essential requirements are found early on. Visionary has the most accurate perception of the business objectives of the system and the project. Another task is to supervise and keep the development process in the right track.
• Ambassador User Brings the knowledge of the user community into the project, ensures that the developers receive enough user feedback during the development process.
• Advisor User Can be any user that represents an important viewpoint and brings daily knowledge of the project.
• Project Manager Can be anyone from the user community or IT staff who manages the project in general.
• Technical Co-ordinator Responsible in designing the system architecture and control the technical quality of the project.
• Team Leader Leads their team and ensures that the team works effectively as a whole.
• Solution Developer Interpret the system requirements and model it including developing the deliverable codes and build the prototypes.
• Solution Tester Checks the correctness in a technical extent by performing some testing, raise defects where necessary and retest once fixed. Tester will have to provide some comment and documentation.
• Scribe Responsible for gathering and recording the requirements, agreements, and decisions made in every workshop.
• Facilitator Responsible for managing the workshops' progress, acts as a motivator for preparation and communication.
• Specialist Roles Business Architect, Quality Manager, System Integrator, etc.

DSDM’s strengths include:

• Basic product functionality can be delivered rapidly
• Developers have easy access to end-users
• Projects are reliably completed on time

DSDM’s weaknesses include:

• Can represent a dramatic and disruptive change in company culture
• Costly to implement
• Not ideal for small organizations

3.Crystal

Crystal is an agile methodology for software development. It places focus on people over processes, to empower teams to find their own solutions for each project rather than being constricted with rigid methodologies.

Unlike more fixed frameworks like Scrum, Crystal recognizes that different teams will perform differently depending on team size, criticality and priority of the project and encourages users to adapt the framework for their individual situation.

For example, a small team can keep itself aligned with regular communication, so it doesn't need much status reporting and documentation, whereas a large team is likely to get out-of-sync and would benefit from a more structured approach.

These are categorized by color, according to the number of people in the project;

• Crystal Clear - Teams with less than 8 people

• Crystal Yellow - Teams with between 10 and 20 people

• Crystal Orange - Teams with between 20-50 people

• Crystal Red - Teams with between 50-100 people

At the heart of the Crystal, a family is seven principles. The first three are compulsory for all Crystal approaches, but the rest are optional and can be adopted if appropriate:

#1: Frequent Delivery

You should deliver code regularly to your real users. Without this, you might be building a product nobody needs.

#2: Reflective Improvement

Look back on what you've done, how you've done it and why. As a team, reflect and decide how to improve it in the future.

#3: Osmotic Communication

Cockburn believed that co-location (having teams in the same physical space) is critical as it allows information to flow between team members, as if by osmosis.

#4: Personal Safety

Team members should feel safe to discuss ideas openly, without fear of ridicule. There are no wrong answers or bad suggestions in a Crystal team.

#5: Focus on Work

Team members should know what to work on next and be able to do it. This requires clear communication and documentation when required.

#6: Access to Subject Matter Experts and Users

Team members should be able to get feedback from real users and experts when required.

#7: Technical Tooling

Even back in the 1990s, Cockburn said development teams should have access to toolings like continuous deployment, automated testing and configuration management. This means errors and mistakes can be caught quickly without human intervention.

Advantages of using the Crystal Agile Framework

• Teams have a lot of autonomy to work in the way they deem most effective

• Teams communicate directly with each other, reducing management overhead

• The framework can adapt as a team grows or shrinks

Disadvantages of using the Crystal Agile Framework

• Lack of structure can slow down inexperienced teams

• Not clear on how remote teams can share knowledge informally

• Lack of rigid planning can lead to confusion and loss of focus

The Crystal method has several essentials, which are known as Crystal properties:

• Teamwork: First is teamwork which concentrates on giving team members tasks and additionally, encourages them to do tasks as a team and not as individuals.
• Communication: Second is Communication. It is the most critical aspect of any project. Proper communication through email or face-to-face is required between Customer and Developers. Additionally, it is vital within the teams as well.
• Simplicity: Third property focuses on the fact that Product Design, Requirement Document, and other documentation have to be understandable and straightforward. It will enable everyone to understand and work more efficiently.
• Reflection: Next property is all about achieving three primary aspects of Reflection, that is:
  • Responding and reporting correctly: Firstly, everyone related to the project should respond as and when required. Additionally, they should provide all the updates on time to make it easy for others to understand the progress.
  • Reasoning: Secondly, this means providing a valid reason for every action. Developers and testers should have the right logic for each of their efforts to not let their activity consider a waste.
  • Reconstruction as and when needed: Finally, Tester and Developers should be well aware of all the stages they performed so that it is easy to reverse and reconstruct coding.

• Frequent adjustments: The team should be able to make the adjustments as per the situation and the required changes.
• Improve processes: Improvement is a continuous process. They can be improved basis customer feedback, internal feedback, from meeting output, after the root cause analysis of any bug.

In the same vein as other Agile methods, Crystal Methodology also promotes on time and frequent working software delivery. It inspires high user participation, adaptability, and exclusions of distractions and any waste.

4. Feature Driven Development (FDD)

Feature-Driven Development (FDD) is a client-centric, architecture-centric, and pragmatic software process. The term "client" in FDD is used to represent what Agile Modeling (AM) refers to as project stakeholders or eXtreme Programming (XP) calls customers. FDD was first introduced to the world in 1999 via the book Java Modeling In Color with UML, a combination of the software process followed by Jeff DeLuca's company and Peter Coad's concept of features. FDD was first applied on a 15 month, 50-person project for a large Singapore bank in 1997, which was immediately followed by a second, 18-month long 250-person project. A more substantial description is published in the book A Practical Guide to Feature-Driven Development as well as the Feature Driven Development web site.

As the name implies, features are an important aspect of FDD. A feature is a small, client-valued function expressed in the form . For example, "Calculate the total of a sale", "Validate the password of a user", and "Authorize the sales transaction of a customer". Features are to FDD as use cases are to the Rational Unified Process (RUP) and user stories are to Scrum - they're a primary source of requirements and the primary input into your planning efforts.

Strengths and Weakness of Feature Driven Development

FDD’s strengths include:

• Simple five-step process allows for more rapid development
• Allows larger teams to move products forward with continuous success
• Leverages pre-defined development standards, so teams are able to move quickly

FDD’s weaknesses include:

• Does not work efficiently for smaller projects
• Less written documentation, which can lead to confusion
• Highly dependent on lead developers or programmers

Scrum, XP, and other agile methodologies all use an iterative approach to deliver software. By contrast, the five steps in FDD require the team to follow a set of engineering best practices as they develop small feature sets in one- to two-week iterations. These five steps ensure that development remains consistent so that the project can grow and new team members can come up to speed much faster.

You may want to consider using FDD methodology if your project grows too large and complex for smaller scrum teams to effectively handle the amount of work. This agile feature-driven methodology is well-suited for long-term projects that continually change and add features in regular, predictable iterations.

FDD is very scalable from small teams to large cross-functional teams because it is designed to always focus on what the customer needs and wants.

analysis between Traditional Software Development Methods (TSDMs) and Agile Software Development Methods (ASDMs)

The main difference between traditional and agile approaches is the sequence of project phases – requirements gathering, planning, design, development, testing and UAT. In traditional development methodologies, the sequence of the phases in which the project is developed is linear where as in Agile, it is iterative.

Traditional software development methodologies are based on pre-organized phases/stages of the software development lifecycle. Here the flow of development is unidirectional, from requirements to design and then to development, then to testing and maintenance. In classical approaches like the Waterfall model, each phase has specific deliverables and detailed documentation that have undergone a thorough review process.

Traditional approaches are suited when requirements are well understood – for example, in industries like construction, where everyone clearly understands the final product. On the other hand, in rapidly changing industries like IT, traditional development procedures might fail to achieve project goals. Below are the major disadvantages of traditional SDLC methods.

Unlike the traditional approaches of SDLC, Agile approaches are precise and customer friendly. Users/Customers have the opportunity to make modifications throughout project development phases. The advantages of Agile over traditional development methodologies include:

• Though the problem statement/business need and solution are defined in advance, they can be modified at any time.
• Requirements/User Stories can be provided periodically implying better chances for mutual understanding among developer and user.
• The solution can be determined by segregating the project into different modules and can be delivered periodically.
• The user gets an opportunity to evaluate solution modules to determine whether the business need is being met thus ensuring quality outcomes.
• It is possible to create re-usable components.
• There is less priority on documentation which results in less time consumption and expenditure.

Agile proposes an incremental and iterative approach to development. Consider Agile Scrum Methodology to get good understanding of how Agile processes work. Scrum Master plays an important role in Agile Scrum Methodology. A Scrum Master interacts daily with the development team as well as the product owner to make sure that the product development is in sync with the customer’s expectations. The following diagram illustrates the lifecycle process in Agile methodologies.

Key points while making the transition from Traditional to Agile methodologies:

• Identify the factors which made the transition necessary
• Everyone, including the user, should be clear about the reasons which lead to the transition
• Identify whether it is a small project or big project
• Note the current stage of the project to be transitioned, whether development has started or is yet to start
• Make sure the team has a good understanding of the new approach and have adapted to their respective roles as per the new approach
• Arrange necessary training for the team

The main difference between traditional and agile approaches is the sequence of project phases – requirements gathering, planning, design, development, testing and UAT. In traditional development methodologies, the sequence of the phases in which the project is developed is linear where as in Agile, it is iterative. Below picture illustrate this difference.