10 Predictions for Web Development in 2011
Cool article on Mashable. I know Mashable is pretty mainstream now, but I agree with pretty much everything in this article. The one thing that continues to kind of bother me is the popularity of Ruby. Like, why is it so popular? It’s like, people are all over it b/c it’s new. I don’t get it. ah well… enjoy:
Agile Soup
OK obviously something happened to get me back into the blogosphere. That “something” is actually two things. First, I spent the whole summer hunched over my table saw building a fireplace and that project is finally done. I am proud of that sucker. I spent a lot of time on the phone with my dad figuring out what I was doing, but we made it happen and that room is damn toasty.
Second, as I recently mentioned, I went to the Higher Ed WebDev conference in Cincinnati. The conference itself wasn’t totally amazing or eye opening, but it did help re-enforce some motivators I had just stewing in my head. We will call it the catalyst.
We will also call these stewing ideas “Agile Soup.” Agile is a model for a software development life cycle. You might even call it a project management methodology. The old, most accepted method was called a Waterfall. There’s also an IBM version of waterfall called RUP, which is what I followed religiously for years. I recently started reading about these crazy developers though in California who were trashing the idea of requirements and actually developing on site with clients instead. Gone were requirements documents. In came user stories and use cases and note cards. It sounded like fairy tail land… until I started reading up on it. Agile sounded like it could be a legit model for small projects so I tried it.
Now I’m not only drinking Agile Kool-Aid, I’m serving up some Agile Soup. This article will serve as a quick intro on how Agile can be thought of as more than just an SDLC and how you can use the principles to run your whole business.
First off, let’s review the AGILE Manifesto. If you’re familiar with Agile, then you’ve seen this before:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
I love every part of that. That manifesto is sort of the creed that drives a software development life cycle, but nowhere in it do you see any detail about how exactly the process works. It’s minimalist. The actual Agile process (or at least the one I use, called SCRUM) involves prioritizing client needs, figuring out how many of these needs can be accomplished in a 2 week development “sprint,” and then delivering, regrouping, and re-prioritizing every 2 weeks until the client decides, “hey, this is good enough.” A colleague of mine at Ohio State, Beth Snapp developed her own version called “Rapid Iterative Development.” Her idea is very similar to SCRUM, where we have this software development paradigm that is based on quick, well coordinated, flexible delivery. It focuses on developing working software in small chunks rather than working on abstract documentation followed by long development periods. I like this quote:
The problem with abstractions (like reports and documents) is that they create illusions of agreement. A hundred people can read the same words, but … they’re imagining a hundred different things. That’s why you want to get to something real right away. – Rework
So the goal is to develop these small chunks rather than spend a bunch of time writing documentation and then disappearing into a cave for months building a monster. This way, you’ll be able to change direction easily. The more expensive it is to make a change, the less likely you are to make it. It’s also a lot easier to completely scrap everything you’ve done in a 2 week sprint than it would be to scrap an entire project. So if you screw up or miscommunicate something, you catch it before you become attached to it and you can scrap or change course before it’s too late. The concept is pretty simple, really.
My first light bulb moment piecing Agile into a business philosophy wasn’t really an “agile” moment at all. It came while listening to someone talk about the right approach to social media. His point was that you have to be authentic. These days people don’t value press releases as much as they value customer comments. A facebook or twitter account that is maintained on behalf of a company by a nameless, faceless PR firm or communications office will get exposed and ignored. But if Bill Gates or Steve Jobs get real, people will listen. So the idea is to embrace who you are as a company and be authentic if you want a successful social media campaign.
Rework
- Planning is guessing
- Ignore the details early on
- Good enough is fine
- Your estimates suck
- Make tiny decisions
- Speed changes everything
After reading that great book, listening to people tell me how being authentic is hot, and really embracing the Agile SDLC, I came up with my own Agile Soup… also known as the Home Base Web Solutions manifesto:
Fostering relationships over volume and efficiencies
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Personal attention over following protocols
OK two of those didn’t change. Get over it. I thought about it for a while and realized that I was just rewording the original Agile Manifesto. The end result is the same though. My business is unique. Each of my clients are unique. Every project I work on is unique. If I stay lean and focus my efforts on rapidly deploying software that meets my core requirements and continually improving both product and process, I can’t go wrong. If I’m focusing on building relationships and collaborating with clients to help their businesses grow rather than negotiating terms and conditions to put money in my pocket, I think everyone is better off because if my clients are successful and they like me, not only will they use me again, but they will recommend me to their friends.
AGILE / SCRUM Project Management in under 10 minutes
I found this excellent video that wraps up AGILE in a nutshell.
Hamid Shojaee covers all the SCRUM bases: product back logs, release back logs, team roles, burndown charts, and more.
Software Development Life Cycle
Overview
This document covers the Software Development Life Cycle (SDLC) for Home Base Web Solutions. Home Base implements a RUP methodology. We know that Agile is the new hot thing, but if you really look at Agile, the processes within each SCRUM can and should closely resemble those of a RUP process. Since Home Base is a smaller shop, no project passes the initiation phase of project management if the estimated time to completion is over a month. We may create a program that consists of several smaller projects, each of which is about a month in duration, but no project can last longer than a month. So if you are really a die hard SDLC nut, you can technically call our process AGILE if you want. Our ideas are the same: Clients want to see results, requirements inevitably change over time, we really like getting paid, and big long processes get confusing. So without further ado:
SDLC Phases
The SDLC phases have been derived from the Rational Unified Process (RUP), the Project Management Institute’s Project Management Body of Knowledge (PMBOK), and Home Base Web Solutions best practices. The following phases cover all the major components of the SDLC while identifying the goals, roles, and deliverables. Each phase will be completed in order as it appears in figure 1.
The Home Base Software Development Life Cycle
Figure 1: The phases follow a modified Unified Process.
Inception
Using business process analysis, Unified Modeling Language (UML) techniques, stakeholder interviews, and collaborative definition of application functionality, the Inception phase produces Scope definition for the project as well as a Functional Specification defining what functions the application must be able to perform. Use Cases, an outcome of Inception, are used to determine functional requirements. Figure 2 shows a diagram of the flow of events utilized during Inception to capture the scope of what the solution will deliver. Inception is a collaborative process working with the customer.
Inception Phase Flow
Figure 2: The steps that take part in the inception phase are depicted in order to produce the final functional specification.
The objective for inception will cover defining the customers need. Once this objective is complete the following conditions should be met.
- A clear understanding of the problem that needs to be solved.
- The current processes that are in use today to solve the problem.
- The benefits of solving the problem and their value.
Deliverables
Once the requirements gathering process is completed the following will be delivered.
- Scope Definition – The original requirements usually created by the client that defines the action items.
- Use Cases (Started) – A document that contains each of the application processes and what each step the application can take after each command. In the inception phase these should end up around 15 percent complete and will be finished in the elaboration phase.
- Functional Specification – A detail specification that entails what is going to get done.
Team Involvement
During the inception phase the following roles will need to participate in the inception process.
- Development Staff
- Product Management
- Project Stakeholders
Elaboration
During Elaboration the project team continues to collaborate with your to create a Technical Design Specification that defines how the solution will complete features defined in the Functional Specification. Figure 3 shows the flow of events to produce a Technical Design Specification.
Elaboration Phase Flow
Figure 3: The elements of the elaboration phase are shown in detail in order to produce the final technical specification.
The objective for elaboration covers taking the captured requirements and further defining them into design documentation that can be used by the development staff to write the end software product.
Industry standard UML diagrams are used to communicate the system to be built. For example, users (Actors) interact with functionality in the system (Use Cases) and are subsequently depicted in a Use Case Diagram (see Figure 4 below).
Example Use Case Diagram
Figure 4: An example use case diagram is shown with the actors and processes. (Adapted from UML Distilled)
The flow of events is depicted as a UML Partition Diagram which is sometimes referred to as a Swimlane diagram (see Figure 5 below). The advantage to this exercise is that it encourages parallel processing of the system and lends itself to multithreaded development and effectively communicates how a system flows.
UML Partition “Swim lane” Diagram
Figure 5: The flow of events depicted as a UML partition diagram. (Adapted from UML Distilled)
Once this objective is complete the following conditions should be met.
- Designer / Developer will be able to take the supplied requirements and determine if enough information has been captured to create an application design.
- A process for gathering additional requirements if information is missing.
- Process for capturing design documentation so developers can create the requested functionality.
- Design documentation will solve the captured requirements and nothing more.
- Completed User Interface designs or Prototypes.
Deliverables
Once the analysis and design process is completed the following will be delivered.
- Technical Specification – A detail document containing how the application is going to be built.
- Completed Use Cases – A document that contains each of the application processes and what each step the application can take after each command.
- User Interfaces – A document or developed prototype that contains example screen shots and details how the application is to be laid out.
Team Involvement
During this stage the following roles will need to participate in the elaboration process.
- Project Management
- Development staff
Construction
During the construction the team builds application components or infrastructure elements per the approved Functional and Design specifications. Sets of milestones are defined to allow project stakeholders to establish checkpoints that ensure adherence to both requirements and schedule.
Once this objective is complete the following conditions should be met.
- Developers have completed coding the application.
- Quality Assurance has tested the application.
Deliverables
Once the software development process is completed the following will be delivered.
- Completed Application.
- Document containing test cases based on the use cases.
- Installation and deployment guides.
Team Involvement
During this stage the following roles will need to participate in the construction process.
- Project Management
- Development staff
- Quality Assurance
Transition
In the transition stage the team supports the client’s execution of their User Acceptance Testing (UAT) plan. Once the UAT is complete the project is promoted to production.
- Quality Assurance has confirmed the production application is working.
- The client has completed User Acceptance Testing (UAT). UAT will be performed in a staging environment prior to production deployment.
- The developed application has been deployed to a production environment.
Deliverables
Once the deployment process is completed the following will be delivered.
- Updated Functional specification, Technical specification, User Interface, Use Cases, and Test Cases.
Team Involvement
During this stage the following roles will need to participate in the transition process.
- Project Management
- Development staff
- Quality Assurance
- Support Staff
- Project Stakeholders
Support and Maintenance
In the support and maintenance phase the application will be monitored to ensure it runs at the intended level of quality.
Deliverables
Once the maintenance process is completed the following will be delivered.
- Documented process for identifying and escalating bug reports. In this will be the validation process and escalation process.
- Documented process for bug assignment and prioritization.
Team Involvement
During this stage the following roles will need to participate in the support and maintenance process.
- Support Staff
- Quality Assurance
Appendix A: Use Case Template
Business Requirements
Business requirements describe the functionality that the envisioned system will provide. The next section provides a short description of the methodology used herein to document requirements this is followed by the requirements. We will provide samples of Use Cases that will be developed in the next phase before application construction begins.
Documentation Methodology
Our experience indicates that a combination of business process workflows and Use Case descriptions provides a highly effective and efficient form of communicating business requirements.
Actors
Actors are considered to be any person or system that interacts with the system being documented. The following sections describe the key Actors (roles) within the system, and how they interact with one another.
| Name | Description |
|---|---|
Use Cases
Use cases provide a detailed business description of how significant actions within a business process are accomplished. They include detailed descriptions of any business rules associated with a function, the expected workflow surrounding an action in cases of success and failure.
Developing Use Cases is an iterative process that involves more detail as new scenarios are discovered and described. Early iterations of Use Cases may contain a very high-level, low-detail view of how an Actor interacts with the system. In some cases, early Use Cases may only contain a Summary and a preliminary list of Actors involved. As more information is gathered, and a better understanding is established, Use Cases begin to mature and details are added to accurately reflect the processes involved.
Use Case Descriptions
Use Case Descriptions contain a written account of the way that Actors interact with the system. Use cases are split into three logical segments, the use case description, the expected workflow description, and the alternate workflow description(s).
Use Case Description Format
For the purposes of this document each topic in a Use Case Description is defined below:
| Topic | Description |
|---|---|
| Summary | The Summary contains a very short description of the Use Case | Business Events | Business Events are triggers that stimulate activity within the business. Business Events must be atomic and observable | Actors | At least one or more of the Actors defined in the system is involved in every Use Case. This topic tells which ones apply. | Assumptions | Any assumptions made in the creation of the Use Case. As details of the Use Case are refined, assumptions begin to disappear. When assumptions are removed or are not present, this topic will contain a simple “N/A” for Not Applicable. | Preconditions | Preconditions identify what must be in place before the Use Case carries out its duties. | Description | The description contains an account of the details in a Use Case. It contains more information than the Summary and describes the aspects of the process not covered by other topics in the Use Case. | Associations | A list of other use cases that this use case is extended by or is used by | Inputs Summary | Summary level listing of data input by the actor(s). Note that inputs in this document will be expanded upon / altered during the development process of the application. | Outputs Summary | Summary level listing of data output by the system. | Alternatives Paths and Exceptions | An alternative path is a sequence of actions in a Use Case that only happens in special circumstances.
An exception occurs when the system forces an Actor through an alternative path rather than the Actor choosing the path voluntarily. |
Post conditions | Post conditions identify what must be in place after the Use Case carries out its duties. | Termination Outcomes | The conditions and results for unsuccessful completion of the use case. | Notes | Information that is not directly part of the use case but arises while working on the use case. |
Events
This section describes the events that occur as part of the fulfillment of the use case detailed in the Use Case Description. The following format is used to describe both the flow of events and any alternate flow(s) that may exist.
| Flow Name | Description |
|---|
The “Flow Name” column is used to group the flow or portions of the flow being described. In the case where a use case has several segmented flows that make up the main workflow, each segment would be named in this column for clarity. The “Description” column contains a description of what will happen at the prescribed point in the workflow.
Appendix B: Quality Assurance Process
To improve the quality assurance process, a set of testing principles should be defined and followed. A Quality Assurance Analyst could help define this process.
There are generally 4 main levels of software testing carried out:
- Unit Testing in which the basic components of the software system are tested to verify that the detailed design for the unit has been correctly implemented.
- Integration testing in which progressively larger groups of tested software components corresponding to elements of the architectural design are integrated and tested until the software works as a whole.
- System testing in which the software is integrated to the overall product and tested to show that all requirements are met. Since the Quality Assurance area is not well developed, it is recommended that System Testing be a manual process. Once the area matures automated test tools can used for regression testing. At the moment, it is suggested to have the regression testing done manually by following the defined test scripts.
- Acceptance testing is a further level of testing in accordance with requirements. Occasionally, Acceptance testing, upon which the acceptance of the complete software is based. The clients often do this.