Building has always been a strength of mankind. Archeologists have well documented man's ingenuity in creating labor saving devices or devices that perform tasks that cannot be easily done by a man. Labor saving and functional tools permeate all disciplines. Software engineering considers tools as one of the key elements in achieving well designed products. Tools help to achieve better quality and more cost effective products via:
-
Improved Communications
-
Coping with Complexity
-
Better Organization
Improved Communications
What's common to all the tools used in software or other design disciplines is that most of them are visual in nature. This is a key psychological attribute because mankind has developed a keen visual sense. Humans can understand graphical representations far quicker than written representations. Almost all humans worldwide given some basic lessons in symbolic representation can understand a graphical representation of a concept. Take for example, building schematics. A German designer draws up electrical schematics for a skyscraper to be built in Japan and whether the electrician is either Italian or Japanese makes little or no difference - they both understand the symbols that are universally practiced within the industry. The key is standards. Having visual representation does not totally remove our obligation to document designs in writing. Visual representations cannot provide all of the detail required so it must normally be augmented with written definitions.
Coping with Complexity
In order to raise productivity more results must be obtained with the same overall economic resources. Quite often, when an increase in productivity is realized, it is negated by demands for increased complexity in the next development cycle because of new business challenges. Exasperating this issue further is the fact that in some companies demand for increasingly complex solution are not met with an increase in on hand expertise.
There is a ratio called the Capacity to Cope which indicates roughly how well an organization is able to cope with increased complexity:
Capacity to Cope = Expertise on Hand/ Complexity of the solution
The expertise can be any combination of tools and people. If complexity of the environment increases over time, then the expertise on hand must also increase with time or the organizations ability to cope will decrease. If fewer effective tools are provided to cope with a given environment over time, then the level of on hand expertise must be very high. Conversely, if there is a high level of effective tools then the required expertise may be lower.
Better Organization
Tools can provide a means to organize artifacts during product development and life cycle maintenance. During development of the product, models and source code may need to be updated and accessed by many people. Documentation needs to be provided. Builds of development and release versions of the product needs to be created. The better the organization of the artifacts the more streamlined the operation will be from start to finish.
Tools by Phase?
Software engineering follows other engineering disciplines in that the total product life cycle can be divided into phases to reduce complexity. Often the divisions overlap and produce ambiguity when one task end and a new one begins. There are many methods for completing phases of a projects and many call for complete overlap of some of the phases. A common definition of phases of a software development endeavor are:
Some of the tools are used throughout the development and into the maintenance phase.
All Phases
Project Management
Project Management tools allow for the reduction in complexity of resources, costs and task required to complete the product. Product development can be segmented into tasks that assigns resources and cost estimates. Milestones can normally be added and reviewed to potentially help correct overtime and over budget items. Graphical representation via Gantt charts can be made.
Requirements Change and Version Control
Requirements are always evolving and it is important to be able to produce an initial version (baseline) to track changes as well as completion of each requirement as they occur. The changes need to have documentation indicating who requested the change and for what reason. This will produce a history of the design that will track the growth of the product. It has the added benefit to allow stakeholders the opportunity to back-out of changes if so desired. Having the ability to track the progress of each requirement can give stakeholders feedback to understand the degree of completion of the project.
During the creation of the projects artifacts, there will be points raised about the integrity of the said artifacts. To help alleviate, the organization burden of capturing these points, a central repository can be used. The process is called Change Management Control and this type of tool often has the following attributes:
- Severity Level assignment
- Human resource defect allocation - individual and/or group
- Time Stamping for each stage of investigation
- Workflow tracking as the issue moves from detection to resolution
Requirements and Analysis
In this phase, the user requirements are defined and refined and can or should include several types of tools:
- Software Project Sizing and Estimation
- Analysis Modeling
- Architecture
- Construction
- System Integration
Software Project Sizing and Estimation
Once requirements and analysis have been produced, they can be used to generate an initial estimation of the completion time given various levels of human resources. The area of software estimation is still in it's infancy and will often have contingencies as high as 100% to make up for various risk factors.
Analysis Modeling
Modeling has been present in other disciplines for over a century. The purpose of modeling is to provide an understanding to all stakeholders of what is to be constructed before the task is fully implemented. Analysis Modeling tools have matured in the late 90's and for some methodologies such as object oriented design there is a clear standard finally emerging.
Architecture
Widespread implementation of architecture in software development was rarely considered till the mid-1990's and therefore the tools available for this segment of the product lifecycle are rare. Most tools consist of standard drawing tools.
Construction
The construction phase is when the product is actually built. Depending on the size and complexity of the product to be created, the construction phase can be the largest section of the overall development effort. The tools available in this phase of development are plentiful primarily because there has always had to be construction or there was no product. Builders in the past had to construct but they didn't have to have all the other artifacts that are now considered important to a well designed product. There are many reason for plentiful tools in this phase, but arguably the primary one is that as the software industry matured the demand for products that could solve far more complex problems escalated. In fact, the software industry has never been able to keep up with the demand for coping with more complexity. Tools used during the construction phase include:
-
Memory Profilers
-
Code Coverage Profilers
- Compilers
- Debuggers
- IDE's - Integrated Development Environments
- Source Control Management
- Code Library Management
System Integration
System integration is considered to occur when subsystems that make-up the system are connected together. Often the boundary of a module is defined during the project management phase because work tasks are conceptually easily split at human resource boundaries. Arguably, the optimal size of a work group is four individuals and this maximum usually dictates upper limit for a model or a subsystem. Tools to aid in system integration really have not been a factor in new product development. For ongoing product life cycle integration, there are tools for integrating preexisting modules that must be merged into a common source base.
