AHW2) Hello I have an agile software development methodology that is proposed by
ID: 3780483 • Letter: A
Question
AHW2) Hello I have an agile software development methodology that is proposed by the combining the two other agile development methodologies, my question is how can I draw its process model that describe it entirely(as drawing graphs). The description of the new proposed methodology is given below:
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 smallclient 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 smalltestcases 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 doseperate 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 completelyindependant 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.
sincerely...
Explanation / Answer
TDD -: Test Driven Development is specification and not validation. Want to write just enough production code to fullfil that test and refactoring. TDD is a programming technique.
The goal of TDD is to write clean code that works.
The steps of first development test driven
1) Add a Test ------->Run the tests ---pass---> Add a Test
fail
|
Make A little change ----pass---> Run the tests -----> Pass(Development stops) ^
| |fail
|------------------------------------------
There are two levels of TDD
1) Acceptance TDD(ATDD) with ATDD write a single acceptance test, or behavioral specification depending on preferred technology, and then just enough production functionality/code to fulfill that test. The goal of ATDD is to specify detailed, executable requirements for your solution on ajust in time basis.
2) Developer TDD -: Sometimes inaccurately referred to as a unit test, and then just enough production code to fulfilthat test. The goal of developer TDD is specify a detailed, executable design for your solution on a JIT basis.
Scaling TDD via AAgile Model Driven Development lifecycle.
#) TDD is very good at detailed specification and validation, but not so good at thinking through bigger issues such as the overall design.
#) How people will use the system or the UI design. Modeling or more to the point agile model-driven development (AMDD) is better suited for this.
lifecycle
1) identify the High level scope
2) Identify Initial "requirements stack"
3) Identify an architectural vision.
4) Modeling is part of iteration planning effort
5) Need to model enough to give good estimates.
6) Need to plan the work for the iteration.
7) Work through specific issues on a JIT manner
8) Stakeholders actively participate.
9) Requirements evolve throughout project.
10) Model just enough for now, can always come back later.
11) Develop working software via a test-first approach.
12) Details captured in the form of executable specifications.
Feature Driven Development.
*) 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 project lifecycle
Develop an overall Model => Build a Features List => Plan by Feature => Design by Feature => Product by Feature.
First four levels are called "Model Storming".
FDD also defines a collection of supporting roles.
*) Domain Manager.
*) Release Manager
*) Language Guru.
*) Build Engineer.
FDD's five steps are supported by several best practices. The first is domain object modeling, the creation of a high-level class diagram and supporting artifacts that describes the problem domain. Developing by feature and individual class ownership are also best practices, as is having developers work together in feature teams. Inspections are an important aspect of FDD. FDD also insists on regular builds, similar to XP, and configuration management. Finally, FDD promotes a best practice called reporting of results, similar to XP and AM's philosophy of open and honest communication.
How would Agile Modeling be applied on an FDD project?
The principles and practices can be clearly applied to FDD's two modeling-oriented steps - develop an overall model and design by feature. The only apparent mismatch between the two processes is FDD's practice of class ownership and AM's practice of collective ownership, but would argue that this isn't the case. FDD's practice pertains to coding but does not to modeling, on a FDD project people work together in teams to model, along the lines of AM's model with others practice, and therefore several people will be working on your shared collection of modeling artifacts.
Related Questions
drjack9650@gmail.com
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.