In this installment of the ITIP, we will look at the technique of learning through analogy in greater detail by understanding how Software is built.
The analogy is, you are building a house in the real world and building Software in the virtual world. We will try to understand how Software is built by drawing a parallel with building a house.
Once you have the title and the papers to your piece of land, the next step is to approach an architect who would be willing to design your dream home. The architect would initially call you and your family over for a discussion (an interview of sorts) to understand what you are looking for. Based on his/her understanding of what you are looking for (your requirements) s/he is going to develop a design (the drawing board design). In a similar way, once a Software project is scoped, you go to a Software architect. The architect will ask you a number of questions (an interview of sorts) to understand your Software requirements. After several rounds of discussions the Software Architect comes up with a Software Design.
All disciplines of engineering are characterized by drawings, Software engineering is no exception. Software engineers, call them diagrams! So, Software architects develop designs in the form of diagrams. These diagrams and the notations that are used in them have been standardized. One such standard is called the UML - Unified Modeling Language.
Once the Architect has a design ready, you approach a mason (or contractor) to construct the house based on the design. In a very similar way, once the Software Design is ready you approach a coder (also called a programmer/developer,etc) to write the code. This act is called construction or coding!
Once your dream home is build you start living in it. Like wise, once a Software is built, the you start using it. As you start using your Software you encounter problems, similar to issues faced once you move in to your dream home! This stage of the Software project is called, Maintenance.
Civil Engineering and Software Engineering
Software engineering is a few decades old, while civil engineering is a far older discipline, thousands of years old. Software engineers have borrowed ideas from other disciplines of engineering to help the rapid development of the field! Interestingly civil engineering has been a very important contributor to Software engineering and you will find a lot in common.The analogy is, you are building a house in the real world and building Software in the virtual world. We will try to understand how Software is built by drawing a parallel with building a house.
How the story unfolds in the real and virtual worlds...
Let say we are planning to build a house in the real world...what is the first thing that you would need? The answer is: Land! We would need a plot of land to build a house. So, we buy a piece of land and build a fence around it to mark the boundary of the land. In a very similar way we start a project (an endeavor with an objective to build Software) and scope it! Scope is the boundary. Building a Software or starting a project without scoping it is a recipe for disaster (or at least a lot of misunderstanding!)
Once you have the title and the papers to your piece of land, the next step is to approach an architect who would be willing to design your dream home. The architect would initially call you and your family over for a discussion (an interview of sorts) to understand what you are looking for. Based on his/her understanding of what you are looking for (your requirements) s/he is going to develop a design (the drawing board design). In a similar way, once a Software project is scoped, you go to a Software architect. The architect will ask you a number of questions (an interview of sorts) to understand your Software requirements. After several rounds of discussions the Software Architect comes up with a Software Design.
All disciplines of engineering are characterized by drawings, Software engineering is no exception. Software engineers, call them diagrams! So, Software architects develop designs in the form of diagrams. These diagrams and the notations that are used in them have been standardized. One such standard is called the UML - Unified Modeling Language.
Once the Architect has a design ready, you approach a mason (or contractor) to construct the house based on the design. In a very similar way, once the Software Design is ready you approach a coder (also called a programmer/developer,etc) to write the code. This act is called construction or coding!
While the house was being built there were a number of checks being done at various point in time to make sure things are going right. These checks are also performed when a Software is being developed. This checking is called Software Testing (also referred to as Quality Assurance). Testing is done at various points in time and is given different names like Unit testing, Integration testing, System testing and User Acceptance Testing (UAT) - not shown in the picture below.
The keywords during Software maintenance are change requests and bugs!
Thanks, for reading and see you with the next installment of the ITIP. Have a nice week!
No comments:
Post a Comment