Introduction to Software Engineering
By Reid Phillips, Senior Software Engineer
I have an idea for some software. Now what?
The processes associated with taking an idea for software and turning it into a reality is referred to as Software Engineering. As software has become more prevalent in our every day lives the processes and procedures associated with Software Engineering have continued to evolve. Though each implementation can be different, often Software Engineering will commonly involve stages such as planning, development, validation, and implementation. Each of these stages, depending on the circumstances, can also be broken down into other stages. For example, planning might actually involve specification, architecture, and design stages. Regardless of what your idea requires, the image of someone hunched over a computer, drinking a caffeinated beverage, and typing furiously only depicts one of many equally important stages in software engineering.
In order to help you understand what you can expect your role to entail as a customer or client in a software project, future posts will discuss some of the Software Engineering stages mentioned above in greater detail. For now, though, let’s give a brief introduction to a couple of common approaches to Software Engineering.
“But that’s my story and I’m stickin’ to it.”
The first methodology, waterfall, can more generally be referred to as plan-driven. Waterfall was one of the first well-defined approaches to Software Engineering and was dominant for many years. Though in recent years it has been increasingly replaced by different approaches, there are still software development shops out there that take this approach. Waterfall was so named because it manages the various Software Engineering stages as subsequent steps where the outputs of a preceding stage (e.g., planning) serves as the inputs directing the subsequent stage (e.g., development). This is analogous to cascading waterfalls. Consequently, plan-driven methodologies tend to be more rigid in their approach to the various stages of Software Engineering.
A customer’s involvement in the waterfall approach is customarily limited to certain aspects of the planning and validation stages. Planning because it is necessary for you to convey your idea to the software development team and validation because you need to confirm that the produced software meets your expectations. This black box approach to the other stages can introduce some unnecessary risk which is why waterfall tends to require more time in planning than other approaches.
“Do the evolution”
The risk just mentioned and other drawbacks caused various Software Engineers to come up with a different approach. The result was the Agile Manifesto which directs the various implementations of what can generally be referred to as the evolutionary methodologies.
From Agile Manifesto we have:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more. Unlike waterfall, agile implementations tend to interleave the various stages of Software Engineering, running them in parallel as required. This is due to the recognition that the various stages will often influence each other in dynamic and unforeseen ways. Consequently, it is not helpful to unnecessarily limit ourselves to a one-way street as in waterfall.
In an agile approach, the customer plays a more direct role in all of the Software Engineering stages. In differing ways, each of the points of the Agile Manifesto necessitates more customer interaction. While some implementations, such as Extreme Programming, dictate that the customer actually join the development team, other implementations choose rather to intentionally involve the customer at regular intervals throughout the project. Either way, by encouraging this regular interaction between the customer and the development team in each of the Software Engineering stages the goal is for communication to be enhanced and misunderstandings and problems reduced.
While the reasons that gave rise to the evolutionary methodologies as an alternative to their plan-driven counterparts are real and significant, it does not mean that waterfall does not have its place. Waterfall still excels for projects that are smaller in scope or must be well-defined up front such as critical systems. Whatever approach you find yourself a part of, hopefully, this introduction will serve to give you a better idea of what will be expected of you as a client.
In future posts, we will introduce some of the various stages of software engineering from the perspective of a client. If you have an interest in custom software development for your point of sale environment, contact our New West Technologies sales team to discuss how our software engineers can make your idea a reality.
Related Article: Software Engineering Planning
***
Reid Phillips has a Ph.D. in Computer Science from the University of Arkansas and along with being a Senior Software Engineer, teaches Software Engineering as an adjunct professor, passing his knowledge on to the next generation. Reid also enjoys playing volleyball during his off time.
