n some software development projects the requirements supporting the business objectives are easily defined, while in other

projects they are more difficult to determine at the start of the project. IT leaders should avoid a "one-size-fits-all" project development methodology and tailor their strategy to maximize project quality and efficiency. Software Development Methodologies Waterfall and Agile software development methodologies are conceptual frameworks for undertaking software engineering projects. They both follow Software Development Lifecycle (SDLC) best practice concepts for software development projects describing each stage of development from feasibility to maintenance. Waterfall Development Waterfall development is an approach to software development that breaks a project into finite phases. Each phase is performed in order, and each depends on the completion of preceding phases. The central idea behind the Waterfall model is that the time spent early on, making sure that requirements and design are correct, can lead to greater economy later in the software lifecycle. For example, a bug found in the early stages of the production lifecycle (such as requirements specification or design) is more economical (in terms of money, effort, and time) to fix than the same bug found later on in the process. Figure 1. The Waterfall Development Approach

Analysis of the Waterfall Development Approach Promises

The Waterfall methodology is the most predicative of development methodologies, stepping through requirements capture, analysis, design, coding, and testing in a strict, pre-planned sequence. Provides a disciplined and structured approach which makes it easy to keep projects under control. Limits the amount of cross-team interaction needed during development. Allows for greater ease in project management since plans aren't constantly being revised.

Realities

While the Waterfall methodology is easy on the manager, it can be grueling for developers. Testing comes at the end of the development phase; subsystem testing can reveal problems with the code that must be rectified quickly. Oversights and flawed design work can seriously affect the budgeted costs and final launch date. Debugging can be complicated since developers are often working on other projects at the end of development, and the needed changes can cut into their productivity and work quality. Leaves no room for feedback anywhere in the process, except at the end of a phase. There is no room for changes once development has begun. It fails to be open to change due to external factors and requirement modifications. When applied to the wrong situations the methodology can give the false expectation of predictability and the reality of cost and date overruns. The deliverable (ideas into working software) is a one time deal, typically several months to several years after start date.

In spite of the negative reality, a Waterfall methodology can be suited to software projects which are stable (such as with "shrink wrap" software) and where it is possible and likely that designers will be able to fully predict problem areas of the system and produce a correct design before implementation is started. Agile Development The Agile development method is characterized as being able to adapt quickly to changing realities. It incorporates planning, requirements analysis, and design, coding, testing, and documenting tasks to release mini-increments of new functionality.

Figure 2: The Agile Development Method

Analysis of the Agile Development Method Promises

Allows for adaptive planning. Project risk is minimized by developing software in short iterations where each iteration is a small project on its own. Allows for just-in-time requirements and the ability to adapt to constantly changing requirements. Less time is wasted on written documentation. The emphasis is on real-time communication, preferably face-to-face, over written documents. Progress is measured by producing crude and executable systems presented to stakeholders and continually improving them. There is continuous client communication the project is very close to the user and relies heavily on client interaction to build the best system that meets the user's needs. Deliverables are short-win, business-focused releases, released typically every couple of weeks or months until the entire project is completed.

Realities

Can result in cowboy coding; that is the absence of a defined development method and team members have the freedom to do whatever they feel is right. There is often insufficient structure and the necessary documentation to maintain and enhance the application on a going-forward basis. Only works well with senior-level, highly experienced developers. Often incorporates insufficient software architecture and design for complex applications. Business partners are often nervous and confused about what they will receive as a final package. They resist iterative requirements work and are not prepared for iterative testing. Output may be surprising. Due to the incremental nature of adaptive planning, the overall result may differ substantially from the original intent. This may be a better result but perceived as a chaotic process. Requires a lot of cultural change for an organization to adopt (if this doesn't already exist). Many tools for development (e.g. project management, requirements management, development tools) were based on the Waterfall approach and require extra work to be effective in an Agile methodology.

An Agile methodology is best suited for development projects that are evolving and continuously facing changing conditions. Well known Agile software development methods include:

Extreme Programming (XP) Scrum Adaptive Software Development (ASD) Crystal Clear and Other Crystal Methodologies Dynamic Systems Development Method (DSDM) Lean Software Development Rational Unified Process (RUP) Dialogue-Driven Development (d3)

Bottom Line IT leaders have an important decision to make when deciding on a Waterfall or Agile methodology for a software development project. One size does not fit all. Back to Knowledge Center

gile software development undoubtedly offers advantages that a waterfall approach cant begin to address. Where the waterfall approach is based in predictability and processes, an Agile approach focuses on adaptability and response time to changing requirements. Another important advantage of Agile over the waterfall model is the recursiveness of the work pattern. This means that we can make modifications to the completed stage in Agile while it is not allowed under waterfall model.

Agile Vs Waterfall Model

It is worth mentioning here that the Waterfall model is the primitive model type and has been implemented in the development phase time after time. Hence in the due course if time developers found many drawbacks in this model which were later rectified to form

various

other

development

models.

The

common element to all of them being the basic phases of the waterfall approach. We can hence conclude that Agile is also another of its successors which has all the advantages of the primitive waterfall model and has also rectified the disadvantages in this evolved model.

Difference between Agile and Waterfall Model

1. The main advantage is the backward scalability in Agile. Under waterfall approach we cannot change the decisions and implementations that we had made under the previous stages. If we want to make changes under waterfall we will have to build the entire project from the scratch once again. 2. The flexibility to error check under any part of the development stage makes Agile more bug free and less erroneous as compared to Waterfall which can only test bugs at the end of the development module.

3. Since Agile provides flexibility to make changes as per customer requirements it is more inclined towards better client satisfaction. This is a real set back for the Waterfall model which doesnt allow any modifications once the module has been completed. 4. Under Agile development modular partitioning of the software can be effectively carried out as compared to its counterpart. Though both of them allows option for segregation the later lacks the modifications in the implementation stage. The rules are set down before the commencement of the project hence it hinders further break down of the logical module. Whereas Agile can be of great help under such situations and can allow simultaneous development of different modules at the same time as per time bound requirement. If we want the project to be more segregated Agile comes as a pain relief for developers.
According to Kent Beck,[8] the Agile Manifesto is based on twelve principles:

Customer satisfaction by rapid delivery of useful software Welcome changing requirements, even late in development Working software is delivered frequently (weeks rather than months) Working software is the principal measure of progress Sustainable development, able to maintain a constant pace Close, daily co-operation between business people and developers Face-to-face conversation is the best form of communication (co-location) Projects are built around motivated individuals, who should be trusted Continuous attention to technical excellence and good design Simplicity- The art of maximizing the amount of work not done - is essential Self-organizing teams Regular adaptation to changing circumstances

An Introduction to Agile Modeling

Search

Home | AMDD | Best Practices | Architecture | Requirements

| Analysis | Design | Documentation | Models | Modeling Style | Contact Us | Announcements | FAQ

Agile Modeling (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. Simply put, Agile Modeling (AM) is a collection of values,principles, and practices for modeling software that can be applied on a software development project in an effective and light-weight manner. As you see in Figure 1 AM is meant to be tailored into other, full-fledged methodologies such as XP or RUP, enabling you to develop a software process which truly meets your needs.

Figure 1. AM enhances other software processes.

The values of AM, adopting and extending those of eXtreme Programming v1, are communication, simplicity, feedback, courage, and humility. The keys to modeling success are to have effective communication between all project stakeholders, to strive to develop the simplest solution possible that meets all of your needs, to obtain feedback regarding your efforts often and early, to have the courage to make and stick to your decisions, and to have the humility to admit that you may not know everything, that others have value to add to your project efforts. AM is based on a collection of principles, such as the importance of assuming simplicity when you are modeling and embracing change as you are working because requirements will change over time. You should recognize that incremental change of your system over time enables agility and that you should strive to obtain rapid feedback on your work to ensure that it accurately reflects the needs of your project stakeholders. You should model with a purpose, if you don't know why you are working on something or you don't know what the audience of the model/document actually requires then you shouldn't be working on it. Furthermore, you need multiple models in your intellectual toolkit to be effective. A critical concept is that models are not necessarily documents, a realization that enables you travel light by discarding most of your models once they have fulfilled their purpose. Agile modelers believe that content is more important than representation, that there are many ways you can model the same concept yet still get it right. To be an effective modeler you need to recognize that open and honest communication is often the best policy to follow to ensure effective teamwork. Finally, a focus on quality work is important because nobody likes to produce sloppy work and that local adaptation of AM to meet the exact needs of your environment is important.

To model in an agile manner you will apply AM's practices as appropriate. Fundamental practices include creating several models in parallel, applying the right artifact(s) for the situation, anditerating to another artifact to continue moving forward at a steady pace. Modeling in small increments, and not attempting to create the magical "all encompassing model" from your ivory tower, is also fundamental to your success as an agile modeler. Because models are only abstract representations of software, abstractions that may not be accurate, you should strive to prove it with code to show that your ideas actually work in practice and not just in theory Active stakeholder participation is critical to the success of your modeling efforts because your project stakeholders know what they want and can provide you with the feedback that you require. The principle of assume simplicity is a supported by the practices of creating simple content by focusing only on the aspects that you need to model and not attempting to creating a highly detailed model, depicting models simply via use of simple notations, and using the simplest tools to create your models. You travel light by single sourcing information, discarding temporary models and updating models only when it hurts. Communication is enabled by displaying models publicly, either on a wall or internal web site, throughcollective ownership of your project artifacts, through applying modeling standards, and by modeling with others. Your development efforts are greatly enhanced when you apply patterns gently. Because you often need to integrate with other systems, including legacy databases as well as web-based services, you will find that you need to formalize contract models with the owners of those systems. Read this article for a better understanding of how AM's practices fit together.

I would argue that AM is an agile approach to modeling, that at its core AM is simply a collection of practices that reflect the principles and values shared by many experienced software developers. With an Agile Model Driven Development (AMDD) (see Figure 2) approach you typically do just enough high-level modeling at the beginning of a project to understand the scope and potential architecture of the system, and then during development iterations you do modeling as part of your iteration planning activities and then take a just in time (JIT) model storming approach where you model for several minutes as a precursor to several hours of coding. Figure 2. Agile Model Driven Development (AMDD).

Another way to look at Agile Modeling is as a collection of best practices, as you see in Figure 3. Figure 3. The best practices of Agile Modeling.

My experience is that these practices can be applied to most software development projects, you don't have to be working on an project following an agile software process (such as XP) to take advantage of the approaches described by AM, although one of AM's goals is to explain how to model when following the XP approach. A project team doesn't need to apply all of the practices, principles, and values of AM to benefit from it -- I have always been a firm believer that you should tailor your software process to reflect the unique needs of your environment -- although it is my opinion that like XP you are much more likely to succeed if you do adopt all of AM.

Recommended Resources
Agile Analysis Agile Model Driven Development (AMDD) Agile Modeling Best Practices Agile Requirements Best Practices Agile Requirements Change Management Agile Requirements Modeling Frequently Asked Questions (FAQ)

Inclusive Modeling Introduction to Agile Modeling PPT Slides (free download) Is Agile Crossing the Chasm? Practices of AM Principles of AM Where Do I Start? The Object Primer 3rd Edition: Agile Model Driven Development with UML 2 is an important reference book for agile modelers, describing how to develop 35 types of agile models including all 13UML 2 diagrams. Furthermore, this book describes the techniques of the Full Lifecycle Object Oriented Testing (FLOOT) methodology to give you the fundamental testing skills which you require to succeed at agile software development. The book also shows how to move from your agile models to source code (Java examples are provided) as well as how to succeed at implementation techniques such as refactoring and test-driven development (TDD). The Object Primer also includes a chapter overviewing the critical database development techniques (database refactoring,object/relational mapping, legacy analysis, and database access coding) from my award-winning Agile Database Techniques book. Agile Modeling: Effective Practices for Extreme Programming and the Unified Process is the seminal book describing how agile software developers approach modeling and documentation. It describes principles and practices which you can tailor into your existing software process, such as XP, the Rational Unified Process (RUP), or the Agile Unified Process (AUP), to streamline your modeling and documentation efforts. Modeling and documentation are important aspects of any software project, including agile projects, and this book describes in detail how to elicit requirements,architect, and then design your system in an agile manner. The Elements of UML 2.0 Style describes a collection of standards, conventions, and guidelines for creating effective UML diagrams. They are based on sound, proven software engineering principles that lead to diagrams that are easier to understand and work with. These conventions exist as a collection of simple, concise guidelines that if applied consistently, represent an important first step in increasing your productivity as a modeler. This book is oriented towards intermediate to advanced UML modelers, although there are numerous examples throughout the book it would not be a good way to learn the UML (instead, consider The Object Primer). The book is a brief 188 pages long and is conveniently pocket-sized so it's easy to carry around.

Let Us Help
We actively work with clients around the world to improve their information technology (IT) practices,

typically in the role of mentor/coach, team lead, or trainer. A full description of what we do, and how to contact us, can be found at Scott W. Ambler + Associates.

Copyright 2005-2012 Scott W. Ambler

This site owned by Ambysoft Inc.

Where Do I Start?

Search

Home | AMDD | Best Practices | Architecture | Requirements

| Analysis | Design | Documentation | Models | Modeling Style | Contact Us | Announcements | FAQ

The first thing to do is read An Introduction to Agile Modeling to gain an understanding of the basic concepts. Regardless of your role, you should actively strive to keep your approach to modeling as collaborative and simple as possible. Recognize that you only need to create models which are just good enough for your task at hand -- models don't need to be perfect (they never are) nor do they need to be complete, they just need to fulfill the needs of their audience right now. Model with others whenever possible, in particular the audience for your model, to ensure that you understand their needs. Of course, you should read and try to adopt as many of the principles and practices of AM as you can and should try to ease into AM gradually. My specific advice for the major roles on software development projects follows: I'm an architect... I'm a data professional... I'm a designer... I'm an enterprise architect... I'm a programmer... I'm a project manager... I'm a QA/Test professional... I'm a requirements analyst... I'm a senior manager... I'm a stakeholder...

I'm an Architect...
To understand how architecture changes within an agile environment: 1. High-level, initial architecture envisioning should be done at the beginning of a project. The goal is to identify a potential architectural solution, not to document the details, typically using simple techniques such asfree-form diagrams on plain-old whiteboards (POWs). This effort typically takes several hours or days. 2. All architectures work on POWs, therefore you need to prove it with code. 3. The details are modeled on a just-in-time basis in model storming sessions, and then coded immediately afterwards. 4. Your architecture will evolve over time as you learn more about what your stakeholders need built. 5. Because systems are complex, effective architects understand how to apply a wide range of modeling techniques. 6. Architects should be active participants on the project team, and ideally should also code. 7. Read Agile Architecture Modeling for more details. 8. The best architects are generalizing specialists who have one or more specialties (e.g. architecture), a broad understanding of IT, and a good understanding of the domain which they work in.

I'm a Data Professional...

The Agile Data site focuses on exactly this topic.

I'm a Designer...
To understand how design changes within an agile environment: 1. Over the first couple of days a high-level, initial architecture model is created using simple techniques such as free-form diagrams on plain-old whiteboards (POWs). 2. Recognize that the concept of a "design phase" has been abandoned for the concept that you need to model throughout a project. Instead, your design emerges over time to reflect the fact that requirements changeover time. 3. Because systems are complex, effective designers understand how to apply a wide range of modeling techniques. 4. The details are modeled on a just-in-time basis in model storming sessions, and then coded immediately afterwards. 5. The quality of your application design is kept high via refactoring, a programming technique. 6. The quality of your database design is kept high via database refactoring. 7. The best designers are generalizing specialists who have one or more specialties (e.g. design), a broad understanding of IT, and a good understanding of the domain which they work in.

I'm an Enterprise Architect...

To understand how enterprise architecture changes within an agile environment: 1. Your goal should be to promote consistent, proven architectural practices and strategies amongst development teams. 2. Start by developing a vision, then get involved with development teams and work with them as part of the team to help them work to that vision. Over time you'll develop architectural documentation, but don't invest much time at first because the teams need vision and help from you, not mounds of documentation. 3. The most important thing your enterprise architecture group can provide to teams is actual help to follow the enterprise vision. The next most important things are working examples (reference architectures) and practical guidance (standards and guidelines) for building systems. 4. Your enterprise architecture will evolve over time as you work with the project teams, because you'll learn what works in practice and what the developers actually need. 5. The best enterprise architects are generalizing specialists who have one or more specialties, a broad understanding of IT, and a good understanding of the domain in which they work.

I'm a Programmer...
To understand the relationship between AM and programming:

1. The primary advantage of modeling is that it provides one way for you to think before you build something. You can draw a sketch on a whiteboard or in a modeling tool to think something through and the once you have a viable strategy then you can prove your model with code. 2. Whenever you run into a requirement you don't understand, perhaps you have a new user story to implement or the requirement simply isn't clear, then you can model storm with your stakeholder(s) on a just-in-time (JIT) manner to get the details that you need. 3. Whenever you run into a technical issue, perhaps you're not sure which strategy to implement something is best suited for your current architecture, or perhaps you simply need to think through the high-level design before you get into coding, then you should model storm with a co-worker(s) (often your pair if you're pair programming) to think it through first. 4. You don't need a big design document written up before you write your code, and you don't even need a lot of details, you just need to create models which are just barely good enough for your situation. 5. I highly suggest that you take a test-driven development (TDD) approach, as I indicate in the AMDD article, and pair program whenever possible.

I'm a Project Manager...

To understand the relationship between AM and project management: 1. You will likely need to schedule initial envisioning sessions at the beginning of the project. 2. Organize your project into short iterations. The functionality that you implement in each iteration should be the highest priority functionality, as defined by your stakeholders, at the time. The requirements stack changes throughout the project, so don't invest much time planning ahead because you'll only need to do a lot of updating. 3. The best people to estimate something are the people building it, and they might need to do a little bit of modeling to understand the feature that they're estimating. 4. Modeling isn't a task that you schedule, it's an activity that people do on a just-in-time (JIT) basis throughout the project. 5. You'll discover that model reviews (requirement, architecture, ...) really don't provide a lot of value on agile projects, so expect to discover that you don't need them after awhile (if at all).

I'm a QA/Test Professional...

To understand the relationship between AM and validation activities: 1. Agile models evolve over time and they are just good enough for the task at hand. The implication is that it's unlikely that you'll have a "complete" model to review, except at the end of the project. 2. Because Agile Modelers work incrementally and prove it with code whenever they can you'll have working software to validate very quickly, so reviewing models really does become busy work. Everything works on a whiteboard, or in a CASE tool, but not always in code. Focus on the code.

System Analyst's blog

by Umut Yigitoglu > www.umutyigitoglu.co.uk <-

Fact-Finding Techniques
Posted on November 4, 2010

1
Fact-finding techniques are used to gather requirements and information concerning the business and the industry it participates in. Interview technique is used to gather user and client requirements in depth. In addition, finding out how the current system works from the views of users, and users expectations from the new system. Also, subjects that require depth information/ knowledge can be discussed by using interview technique such as: budget, company background and so forth. Observation technique is used to observe the business and current system; also to note down requirement and facts that has not mentioned in the interviews. This is a highly successful technique, because developers have the chance of experiencing the current system themselves, not just relying on the words of the users. Questionnaire is used to take the views of large number of groups. For the project a questionnaire was produced regarding on the home delivery service and handed out to the customers to understand their buying pattern. Prototyping and storyboard is the visual technique, which is used to conform the understanding of the system requirements that users and client required. Also, at the interface stage is the main techniques to determine the layout and navigation through windows. In addition the technique has the ability to bring the users and developers together, which will increase the changes of success. Use-case diagram is the description of a particular interaction between the system and one or more of its users. The role is to show the functionality of the system from the user perspective. Also, it shows the interaction between tasks and activities., which is useful at the stage of conceptual and logical design where entities, attributes and relationships are identified, then ER diagram produced.