Academic Integrity: tutoring, explanations, and feedback — we don’t complete graded work or submit on a student’s behalf.

sincerely... Agile Methodology Assignment Propose your own agile software develo

ID: 3583955 • Letter: S

Question

sincerely...

Agile Methodology Assignment Propose your own agile software development methodology (10 points) First of all, find a good name for your agile methodology. The name should be impressive like "Extreme Programming". And, explain why you name like that. (5 points) Secondly, determine a duration for your iterations. Explain why you choose that much time for your iterations (50 points) Thirdly, in your agile methodology, you will emphasize the following 5 agile Concepts o Adaptation o Communication o Customer Satisfaction and Business Value o Frequent Inspection o Retrospective Your agile methodology will try to maximize each of the above agile concepts. o For each of the above agile concepts, propose a corresponding practice that should maximize the related agile concept. o Each practice should be different from the known agile practices. At least, there should be some differences from the known practices o For each practice, explain how you use it in your iterations. In other words, integrate your practice to your iterations. Explain that integration o For each practice, explain how it maximizes the corresponding agile concept. (5 points) Fourthly, describe what are done before and after iterations. (10 points) Fifthly, describe how you can apply your agile methodology to large projects. In other words, for scaling, how will your methodology behave? (20 points) Lastly, draw the process model of your agile methodology. It should be an original drawing and it should represent your whole methodology The assignment should be at most 3 pages.

Explanation / Answer

I have already answered !!!!!!!!!!

1. The new Agile methodology is "Feature and Test Driven Development".

2. Feature Driven Development (FDD) is an iterative and incremental Agile methods
for developing software. This is client centric pragmatic Software process.
As the name implies, "Features" are important in FDD.
A feature is a small client valued function expressed in form of
action - result - object.

Test Driven Development (TDD) relies on repetition of development cycle -
i.e. write a test before we write the production code to fulfill the requirement.
Goal of TDD is specification and not validation.

We can combine this FDD and TDD to form new "Feature and Test Driven Development"
(FTDD).

In FDD, we concentrate on feature based on client request and do the development.
We only think of testing once the development of the feature is complete.

In TDD, requirements are turned into small testcases and code is improved to
pass the test case.

We need both the approach for effective Software development and delivery.

Once we get the requirement from customer, we can do FDD and TDD in parallel,
so that testing and development happens in parallel and there is no wastage of time.

3. We can have the project flow as below.

once we get the requirement, we can have 1 week time for FDD and TDD to happens
in parallel.
So that in one end, FDD team can concentrate on developing feature.
And, TDD team can develop suitable test cases so that they can check the feasibility.

4. - Adaptation -> Based on the complexity of requirement, we can have change
                   in 1 week duration time.
                   With this approach, FDD team need not do seperate testing.
                   And TDD team need not write production code after introducing
                   test cases.
                  
   Communication -> FDD and TDD teams can communicate each other for the
                   new feature interface and help each other.
                     
   Customer Satisfaction and Business value ->
                   With FTDD approach, there is lot of time saved.
                   For example, FDD team need not do write test cases to
                   test the feature.
                   TDD team after verifying the requirement need not write
                   production code and that time is saved.
                   If TDD team finds that requirement is not feasible, then
                   it can discard the code developed by FDD.
                  
   Frequent Inspection and Retrospective ->
                   Here FDD teams and TDD teams are completely independant and
                   only need to communicate and start requirement analysis and
                   after either developing code or writing the test cases.
                  
                   By this the retrospective time for completion is reduced by a week.