Software Development Methodology


Every project, small or large, should have some basic structure or process (methodology) it must follow. This could be a simple one-page checklist or a slightly more formal process. Having no process at all is bad, but too much is equally bad. Finding the right balance depends on the customer's needs and the project size, but in summary, I lean toward having less process with minimal (and "good enough") documentation requirements, rather than having a bloated process that can bog down the customer and developers in paperwork and procedures. In this chapter, I'll provide a basic software development process based on XP and AMDD.

Overview of XP and AMDD

XP and AMDD provide some fundamental guidelines for building software applications effectively and rapidly. XP and AMDD are complementary methods because XP provides a disciplined, full life cycle software development approach that stresses customer satisfaction. AMDD, on the other hand, generally provides effective practices for modeling and documentation, but goes a lot further by providing a wealth of additional best practices that can be tailored to each software development project.

Personal Opinion: Why Agile Modeling and Extreme Programming?

In recent months, I have become quite fond of the Agile Modeling (AM; agilemodeling.com) values, practices, and principles (see cheat sheets in Appendix J). Similarly I have also grown fond of Extreme Programming (XP; extremeprogramming.org). Furthermore, what makes me even more confident about these methodologies is the plain and simple fact that I have yet to hear anything bad about these methodologies from any developer who has actually worked with them. I'm talking about some very intelligent people who are either working with these two methods or promoting one or both.

AM is about modeling and documentation in an effective manner using simple tools. XP, on the other hand, is a full development life cycle. Both of these align very well with my views on software developmentviews that are based on experience I have gained over my jam-packed 20 years in IT working for a dozen or more very large, and also some small, companies.

Prior to AM and XP, I had worked with the Rational Unified Process (RUP) and before that some custom home-grown methodologies. Even though I enjoyed using RUP for a while, I began to find RUP a bit on the heavier side when it came to requirements documentation and up front architecture and design; at least this is how I see most organizations using RUP. On the other hand, AM and XP are nimble methods!

It takes a bit of time to get the hang of it; some of this is because of internal resistance to change or misconceptions about XP. However, when you do get it, it does feel good! It feels so natural that you have to sit there and wonder why it took so long. Seriously, these two methods are getting more and more popular by the day because they feel so natural to developers.

Another reason XP and AMDD might take a little getting used to is because these methods don't work in a linear fashion. This is the case because things don't always work in a linear fashion in the real world. Also, this approach facilitates change better than the rigid linear methodologies in which all the requirements must be locked down up front and the customers have their hands slapped if they request too many changes. Change is inevitable, so it is better to deal with it by embracing it. Trust me, it took me a little getting used to because I had been working in the linear/rigid mode for years before discovering XP.

Incidentally, the term Agile refers to a wide range of software development methodologies. In 2001, the term Agile was collectively agreed upon by representatives of methods such as Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others (see manifesto and history at agilemanifesto.org). The agilemodeling.com website takes this into consideration and serves as a one-stop website for getting a wealth of knowledge on these methods at your fingertips.

AMDD is more specific to development. I chose AMDD for this book because in addition to the fact that the AM viewpoint aligns with my own, I also like that AMDD proposes just good enough modeling artifacts (such as free-form architecture diagramsmy favorite kind). Perhaps these words from the AM website best summarize my feelings about producing artifacts: "Your goal is to build a shared understanding, it isn't to write detailed documentation." Need I say more?

On the XP side, you will find many of concepts used in this chapter and throughout the book; concepts such as user stories, CRC cards, test-first design, release and iteration planning, and more.

I have already stated reasons why these are popular with developers. However, customers love this style of working, too, because both methods are customer focused and require active stakeholder participation. Granted, this does require more of the customer's time, but they are pleased to see constant progress; as a result, fewer things can go wrong with a project because ongoing communication exists between the customer and the developers.

Ongoing communication with the customer also helps the developers stay focused on the end goal and understand the problem domain better and faster. Hence, understanding the customer's problem or need and staying focused on it throughout the software life cycle is essential. By having ongoing communication and easy access to the customer, this task becomes a lot easier.

Let me summarize why this makes so much sense by providing you the end-to-end process using XP. Your team builds and unit tests software daily; the application is integrated often (maybe even continuously as unit tested code is checked in); a production-ready version of the application is deployed every two weeks (iteration); and the customer gets to test drive or fully use the newly added functionality every two weeks (with a full release every two months).

All in all, it is a win-win situation for all project stakeholders.


Although I have some fundamental practices I use on all projects, I typically pick and choose what applies to each project and customize the software development process based on the needs of that project and customer. For example, in our sample project/application in this book, Time Expression, I have used several of the techniques described next and shown in Figure 2.1 (refer to agilemodeling.com/essays/agileModelingXPLifecycle.htm for details). Note that although I have adopted the XP and AMDD way, there might be a few spots where I customize these methods (Project kick-off, for example) to accommodate what we need for Time Expression.

Figure 2.1. The XP project life cycle
(source: agilemodeling.com/essays/agileModelingXPLifecycle.htm); original diagram by Don Wells (http://extremeprogramming.org).


Exploration Phase

The Exploration Phase (Beck, 2000) typically involves a combination of exploratory activities that help you better understand the customer's needs and subsequently how the resulting application will be designed and built. The following are some examples of activities that might take place in this phase of the project.

  • Domain model A domain model helps to define major business concepts (entities) and the relationships among them.

  • User interface prototypes and storyboard These are initial screen mockups to get a feel for how the customer visualizes the application. The storyboard is the flow of the screens.

  • User stories A few user stories get the project started and make up the first release or version of the application. User stories (similar to shall statements in other methods) are written by the customer in a brief sentence or two explaining what the customer wants the application to do. Note that the number of user stories you gather up front will depend on the project, but you should have enough to make a good and useful release.

  • Scope definition It is important to define the scope of the project up front so that you know what needs to be developed and what can be deferred. It also clarifies the customer's expectations.

  • Analysis This can include a combination of whiteboarding, an informal architectural diagram, a glossary, and more.

Planning Phase

Planning can mean different things to different people. For me, it should at least include the following:

  • Release plan This is essentially a plan for the next release (version) of a system and can easily be put together using a spreadsheet program or even a word processing program and/or HTML table. It lists all the user stories that will be included in the next release of the system, grouped together in several iterations. Releases are typically of fixed length, anywhere between one to three months; two months is typically an optimal size.

  • Iteration plan An iteration plan is developed prior to each iteration. It includes the user stories the customer wants implemented in the next iteration. Iterations are typically of fixed length, anywhere between one to three weeks; two weeks is typically an optimal size.

  • Define standards (code, database, process) Before beginning any development, it is a good idea to standardize such things as coding conventions, database naming conventions, processes (build, integrate, deploy), and more.

Active Stakeholder Participation

According to the agilemodeling.com website, "Active Stakeholder Participation is an expansion of eXtreme Programming (XP)'s On-Site Customer that describes the need to have on-site access to people, typically users or their representatives, who have the authority and ability to provide information pertaining to the system being built and to make pertinent and timely decisions regarding the requirements, and prioritization thereof."

Given this, I would recommend to always do release and iteration planning with the customer and developers. Remember, successful projects are typically ones where the customer is actively involved (hence, the phrase Active Stakeholder Participation).

For more details on active stakeholder participation, you may want to read the following essay on the AM website: agilemodeling.com/essays/activeStakeholderParticipation.htm.


Iterations to Release Phase (Building Software in Increments)

Iterative development is a term you are probably familiar with. However, understanding of iterative development and what each iteration should include varies from person to person and from methodology to methodology.

For me, iterative development means that each iteration includes design, coding, user acceptance, and deployment of "production ready" code. This code can be deployed to the production environment or, if you are in a large corporation and deploying to production frequently is not practical, perhaps deploying to the acceptance environment will do, so long as it is accepted by the customer, thus allowing you to move on to the next iteration. To summarize, each iteration might include the following activities:

  • Development tasks, estimates by developers, and a plan for the next iteration.

  • Ad hoc Q & A between developers and the customer.

  • Design CRC cards, UML diagrams, and so on.

  • Code test first, refactor code/database/architecture as required, optimize later.

  • User acceptance testing (UAT).

  • Deploy iteration to production (or UAT); this step is also referred to as a small release.

By delivering iterations in this fashion, you can incrementally build the next release of an application. For example, we might estimate three months for a given project and break it down into two-week iterations, resulting in approximately six iterations.

The bottom line at the end of each iteration is that the project should be deliverable; in other words, the small releases should contain production-ready (stable) code, even it provides only a subset of the complete system.

Scope of Project

The scope of project can be defined in many formats. Sometimes it is as simple as a oneto two-line paragraph described by the customer, or it can be more structured using diagrams. Many organizations go one step further and sign service level agreements (SLAs) with the development team. Also, functional and nonfunctional requirements discussions can also occur to help define the scope.

In the past, I have used a table to show what is included in the scope and what is deferred (or excluded) from scope, as demonstrated in Table 2.1, a sample scope table for Time Expression.

Table 2.1. Sample Scope Table

Scope

Functionality

Include

Time Expression will provide the capability to enter, approve, and pay for hours worked by employees.

Defer

Time Expression will not calculate deductions from paychecks, such as federal/state taxes and medical expenses.

Defer

Time Expression will not track vacation or sick leave.


Maintenance

This is where the application enters a maintenance state. This phase might include training for the user, minor enhancements/fixes (in the form of user stories), as needed. Or the customer might want to do another major release, in which case you would start back from the Exploration Phase mentioned earlier in this chapter.



Agile Java Development with Spring, Hibernate and Eclipse
Agile Java Development with Spring, Hibernate and Eclipse
ISBN: 0672328968
EAN: 2147483647
Year: 2006
Pages: 219

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net