:part1
As a student, it’s very easy not to think about the practical applications and real life work flow of the code you are learning to write. Obsessing over syntax and trying to make everything work the way it should can often overshadow the logistics and organizational practices of working on a large project with multiple people. We do paired programming exercises, which mimic some sort of work place environment and teach us how to get along and work well with others, but there is no real hierarchy, and while they are incredible, absolutely useful and definitely necessary, they seem to fall short in giving the full experience of working on a real life, bonafide software engineering team. Or so I am told.
I have grown to truly love coding and the way it pushes me and makes me think critically. I am incredibly excited to make it my career, to do it everyday, and be a part of a team that’s purpose is to create something great. My past career did not have me in an office working with groups of people in a super structured way, which almost concerns me when I think about getting a job after school ends, so I decided to take a quick look further into how these development teams work on their products.
Waterfall Development
The Waterfall model is a linear approach to design, meaning the progress flows in one direction. Historically, it was used to design and build structures, like bridges and buildings, which is a great way to do that, but does not seem to work as well when applied to things like software.
Waterfall Model Phases: these phases are not set and stone and can changed depending on the team or product, but the basic ideas are here. It is important to note that the waterfall model flow usually depends on each step being fully completed, reviewed, and verified by the powers that be before moving to the next step. However, people make mistakes, so the system is flexible enough to repeat steps if the completed steps are not deemed acceptable.
- Requirements: documentation detailing the required functionality and anything else that the product needs to do or have.
- Analysis: team looks at requirements to start building models, schema, and business rules that are necessary for the finished product
- Design: team starts to design the basic architecture of the product or software. This step results in the software architecture, seen above.
- Coding: developing and integrating the software or product, which results in the software, seen above.
- Testing: debugging, finding issues, etc.
- Operations: installation, support and maintenance of the finished software or product.
Pros:
- It needs to be organized well to function: the flow helps the team focus on the important details fully and completely before moving on to the next steps
- Places a lot of emphasis on documentation: this includes the requirement docs and the design docs, which are all important and keep everyone informed, especially if the team changes throughout production.
- It is a simple structure: the whole process is laid out plainly and is easily understandable
Cons:
- It needs to be organized well to function: this is harder than it sounds and can lead to problems if it is not organized well.
- The flow depends on the Client, or user, needing to know exactly what requirements they have when the project starts, which is easier said than done. Costs are increased when the requirements change mid production, since the team essentially has to start over.
There have been many adaptations of the waterfall model, which leads us to the next big step: Rapid Application Development, or RAD.
RAD(Rapid Application Development)
RAD came to be in response to the short comings of the waterfall model when it came to software development. It is a term that applies to a general idea as well as a specific model created by James Martin. Perhaps the biggest difference between RAD and waterfall is the implementation of prototypes. Having a usable prototype during development means that the client, or user, can interact with the product before it is completed and as it is being created.
RAD method: below is a walkthrough of James Martin’s RAD method
- Requirements planning: like the waterfall model, RAD has a step for planning and analyzing before jumping into creating the product. Everyone on the team gets together to layout and agree on business and technical needs, as well as project scope, constraints, and system requirements.
- User design phase: The client, or user, works together with the analysts to create models for a prototype that gives a general view of the overall system. This step helps the client, or user, understand what is happening in the process and allows them to approve a working model of the system.
- Construction phase: The product continues to be developed into a functioning system. The client, or user, continues to work together with the development team to give feed back and approval. This is the step when the actual code is written and the product is made. This step is repeated with the user design phase until the product is ready.
- Cutover phase: The product is tested and implemented in this phase.
Pros:
- The iterative nature of RAD allows for an easier time adapting to the client, or user, needs and requests, which leads to a higher quality product.
- Risk factors in the plan are noted early and can be adapted to much easier than in the waterfall model.
- Faster and cheaper. RAD is said to deliver a product in budget and on time more than the waterfall model. The iterative design of RAD allows the development to happen in smaller pieces that build as the process continues, which, usually, keeps any catastrophic problems from arising. Apparently, it was common place for things to get out of hand while using the waterfall model if the team needed to change a piece of the system that required a total overhaul of the product.
Cons:
- Change is hard. At first, this new approach was difficult to implement because humans fundamentally do not like change. It would be hard for a team to switch gears so rapidly if they were coming from the waterfall model.
- Client’s Employee. The advantage of having the client, or user, work with the development team is invaluable for the developers, but can often be difficult for the clients. It is highly likely that the client’s representation in the process will be a higher level employee that has a deep understanding of the domain. This means that the business will have to be without this high level employee for quite some time, which may not be what the company wants.
- Scalability. RAD works well with smaller teams, but can often be hard to implement with larger teams on larger projects because it requires so many people working together, side by side.
- Design problems. This model can often lead to a “hack and test” mentality while working on the product, since it is always changing, it is easy to abandon the overall process’s structure.
Conclusion
- The RAD method seems to make much more sense to me. I can see why the waterfall model would be used, but RAD seems like the only way to work with today’s products. This is just a small intro to all of the processes out there, I will likely be posting about more relevant techniques soon!
::Stay tuned for :part2: Agile Software Development and Scrum!::
Sources:
