Planning, design and management are the core activities used to drive an engineering project from its inception through to a successful conclusion. These are essentially problem-solving processes.
| Engineering Design | The Engineering Design Process I |
| The Engineering Design Process II | |
| Agile Software Development | Software Development Methodology: What is Agile? |
| An Overview of Agile Development | |
| Intro to Scrum in Under 10 Minutes |
Assignment 2 - Software Defined Network Traffic System
An ill-defined problem is one that is vaguely or ambiguously formulated. There are good reasons why engineering problems are initially poorly defined. Even when an engineering problem has been clearly formulated and stated, it will be open-ended, in the sense that there will not be a single "correct" solution. Indeed, a characteristic of engineering problems is that there are alternative, potentially acceptable solutions. The problem is not to find "the" solution but rather to find the "best" solution.
At the commencement of an engineering project, the initial state will not be known precisely and the target state is still undefined. In some situations it may be very difficult to identify the required target state and, in a worst case scenario, it will not be possible to know whether the correct engineering decisions have been made until the project has been completed. The open-ended nature of engineering work raises a number of important questions. In particular:
In engineering work, it can be useful to draw on past practice for ideas for solving current problems. However, it is dangerous to rely exclusively on this approach. Adaptation is always needed, because differences inevitably exist between past and present engineering problems, and great care must be exercised to ensure that these differences are allowed for.
Question: Is it a good idea to keep a repository of reusable code?
Answer: Yes, absolutely!
When faced with a problem that is both ill-defined and open-ended, common sense suggests that the first step should be to clarify the problem and re-state it in clear and unambiguous terms, in so far as this is possible. If a range of alternative approaches can be found, after the problem has been clearly formulated, then the initial instinct may well be to choose the most "obvious" one and develop this into a solution.
On reflection, however, it becomes clear that intuition alone will not lead necessarily to the best, or even to a good, solution. Rather than concentrating initially on a particular solution, it is better to take just the opposite approach and look for as many different solutions as possible, that are feasible and promising. To be able to do this, we need to formulate the problem in general (not over-specific) terms so that unusual but promising solutions are not excluded.
Question: In software engineering terms, what do you call an approach where you assume an answer, then
work backwards to see if the answer is correct?
Answer: A heuristic algorithm. Also referred to as an NP problem. See
Heuristic algorithms
Our search for unusual but promising ideas will not be successful if we use convergent thinking and rely on an analytic approach. We need to use divergent, lateral thinking. Creativity is extremely important because we are seeking unusual, non-routine solutions.
If we are successful in creating a range of different and promising solutions to our problem, our next task is to evaluate them, compare and rank them and hence identify the best approach. These simple thoughts lead to a problem-solving strategy which can be applied to poorly formulated, open-ended problems. The steps are listed below.
Question: With such an approach, would it be useful to assign numbers to each criteria and a weighting factor for each criteria?
Answer: Yes, that is often what's done. A qualitative approach is also useful.
The strategy above will be appropriate for relatively simple, open-ended problems where it is easy to evaluate and compare the alternative options. This may be the case in simple activity planning tasks. If, however, the problem has many, relatively complex, alternative solutions (and this is typically the case in engineering work) then an enormous amount of effort would have to be expended in the third step. A full set of designs and plans would have to be created for each approach. This would be extremely time consuming, costly and inefficient, because it would mean solving the detailed problem many times, once for each option.
The costs in time and effort in the planning and design phases can be reduced enormously if, instead of fully evaluating every option, we use an incremental approach, and start with simple and rough comparisons of the options. On the basis of quite limited information it will usually be possible to identify and eliminate the less competitive options. This first step is not costly because we are using simple, approximate, order-of-magnitude calculations. A second, rather more detailed, evaluation of the remaining options then allows a further cull to be made.
Proceeding step-by-step in this way, we eventually identify a single best option. If not, we will at least have a short list of the most promising options and we can then proceed to a final round of comparisons in which we use the most accurate analyses and calculations. With this methodology we substantially reduce the total amount of effort. Furthermore, the more detailed calculations are made for the more promising options. The steps in this modified methodology are listed below.
As the design and planning work proceeds, it will often become clear that a modification, improvement or correction is needed in one or more of the steps already completed. In Step 4, for example, when a new and unusual, but promising, approach is being evaluated, it might be found that the original problem statement in Step 1 is unnecessarily restrictive. Rather than staying rigorously with the original problem statement it is best to go back and restate the problem in a more encompassing way, as our aim is to obtain the best solution. Likewise, when alternatives are being compared and ranked in Steps 5 and 6, it might become clear that an improved problem statement will allow improvements to be made to some of the approaches.
A methodology for undertaking engineering planning is shown below. It follows closely the problem-solving methodology listed above but typical feedback loops have been added to emphasise the need for iteration.
The overall aim of the initial problem formulation phase is to clarify and, if possible, quantify the problem.
The feasibility study is the second phase of the process. This term emphasises that there might not be a feasible solution. The desired outcome from this step is of course a short list of acceptable approaches, which will demonstrate feasibility.
Question: What greatly helps a feasibility study?
Answer: A working prototype with limited functionality.
In the third phase of the process, preliminary planning, further rounds of comparisons and evaluations are carried out, in order to identify the best option. The comparisons now require more detailed analysis and evaluation than previously. If one of the alternatives stands out clearly from the others, then the preliminary planning phase can be quickly and easily completed. On the other hand, if the alternatives are closely matched, this phase can become protracted because of the need for increasingly detailed comparisons.
The purpose of the detailed planning phase is to take the best option, when it has been identified, and develop it to work out all of the details needed to undertake the implementation. If much analysis and evaluation work has already gone into identifying the best option, then there will be correspondingly less detailed planning work needed. The end result of this phase is a detailed plan for implementation. However, this might still not be the final plan. Problems can arise during implementation that make it necessary to revisit some of the earlier steps. Indeed, the plan will not be finalised until the project is completed.
The last phase, implementation, may require the construction or manufacture of new components of infrastructure or the implementation of new processes. At first sight, implementation may seem to be a separate part of the project, to be undertaken when the planning and design work has been completed. This is not so. Whatever form the implementation takes, it is almost always necessary to return to and revise some of the earlier planning work.
Question: Which is more costly, to fix a mistake in the problem formulation, or a mistake in implementation?
Answer: problem formulation, because you have to make modifications to all the steps below it.
Question: What percentage of the schedule is spent on Design? Implementation? Testing and Rework?
Answer: 20% design, 40% implementation, 40% testing and rework. This ratio varies widely. Some put much more
weight on design and less on implementation. Testing and rework is always takes a large chunk of time.
Question: How true are these ratios with the assignments you have done so far?
Answer: 40-20-40, 30-30-40, 60-15-25, 30-50-20, 20-40-40, etc...
Question: When you look at the approach to design so far, which project management methodology is more suitable,
the waterfall model or the agile model? To help you, take a look at the software development life cycle:
ProductDevelopment.pdf.
Answer: For small projects, waterfall is more suitable. For large projects (and for most projects), agile (or iterative)
is more suitable, where the waterfall model can be used in sub-components of the project. The waterfall model must be
used for projects which require a high level of security or reliability, where all features have to be implemented before
the project can be deployed. See
Agile vs Waterfall, What's the difference?.
Question: Within your own company, which departments do you think you have to consult with, while working out the
design and implementation of the project?
Answer: Marketing and Engineering typically work very closely together, manufacturing, human resources (if
we need to hire), finance for financing, customer service, the test group...
The design process shown below parallels the process of engineering planning shown above, although there are some differences in terminology. The emphasis here is on finding alternative concepts, or design options, rather than on investigating feasibility. Despite this difference in wording, the aim of the second phase is the same in both design and planning: to produce a short list of the best feasible options for solving the problem.
The most general, far-reaching and financially most important design decisions are made in the initial stages of the concept design, when new, original and unusual approaches are sought. As the design proceeds towards the detailed phase, the design decisions become more and more specific, and they have less impact on overall costs.
The purpose of the preliminary design phase is to study the short-listed concepts in sufficient detail to allow the best concept to be identified. If it is difficult to choose from several very good concepts, then successive rounds of calculations and comparisons of increasing complexity are needed. These studies may become, in effect, detailed designs. It is not unusual for the preliminary design phase to blend into the detailed design phase, with detailed designs being carried out for several of the very best options.
In the detailed design phase, the aim is to take the best approach, now identified, and generate all the information needed to allow full implementation. If one concept has been clearly identified at an early stage as the best, then a fair amount of additional, detailed work will be required in this phase. On the other hand, the effort needed in the detailed design is correspondingly reduced when the chosen concept has already been investigated in some detail.
Something which is often forgotten or misunderstood is that the vast majority of the work involved in design is finding out what the problem really is - and it's rarely what you think it is. More often than not the client is asking the wrong question. Once you've found out what the problem really is, then things virtually design themselves because you've so comprehensively understood the problem that the solution is self-evident.
The table below contains a checklist of actions that can assist in the problem- formulation phase of engineering planning and design. Some of the actions are information-gathering activities while others are aimed at formulating and, to the extent possible at this stage, quantifying the problem.
An engineering project can begin as a response to perceived needs in the community, and the objectives may be initially poorly defined. The problem as stated may be too vague; alternatively, the problem may be stated in over-precise terms which imply an "obvious" solution. In the latter case, the implied solution will rarely be the only possible one, and may not be the best one. It is therefore important to begin the problem formulation phase by trying to identify the problem as part of a wider or larger problem.
Question: A remote village in South America was identified as one requiring a well. The villagers had to walk for
at least half an hour to a nearby river and bring water back to the village. A social worker therefore
initiated the construction of a well for the villagers. The villagers did not use the well. Why?
Answer: They did not use the well. It turns out these villagers met members of other villages at the
river. The trip to the river was not just for water. It provided a social function.
Question: A remote village in South America was having a mild problem with famine. A social worker received funds
to aid to assist in the resolution of this problem. Instead of buying more seed and better farm equipment,
the social worker decided to let the villagers decide how to overcome this problem. They took the funds and
cleared out a field, put two goal posts at either side, and had soccer games instead. Do you think this
worked in alleviating the food problem?
Answer: Actually it did. The leaders of the village noted the low morale of the villagers and figured
weekly soccer games would go far to improving their social cohesion. As a natural result, they worked more
effectively in the fields during the week and food production improved.
To assist in identifying the problem as part of a wider problem, it can be useful to identify the relevant engineering system as a component of a larger or wider system.
How far should the process of problem broadening be taken? At some stage the problem broadening argument breaks down. How do we recognise this stage? The questions cease to be relevant when they are so broad that new issues will barely influence the problem statement. This occurs when the expanded system is so large that the original problem (in this case, the need for a bridge, or some alternative) ceases to be relevant. When this happens, we have clearly gone too far. The limit, where the problem has been widened to the extent that the original problem is of marginal relevance, is referred to as the interest boundary for the problem. The relevant solution options will be found within this boundary.
The construction of a large bridge in a small country can become an international issue. An example was the K-B Bridge in Palau, a small island nation in the Western Pacific, somewhat less than a thousand kilometres west of the Philippines. The bridge was constructed in the 1970s with aid money from the United States when Palau was its protectorate. At the time, the bridge was the largest prestressed concrete box-girder cantilever arch construction in the world, linking the two main islands of Korror and Babeldaob. It served a crucial purpose for the whole population of Palau because essential services, including the airport and power generation equipment, were located on one island while most of the population lived on the other. The bridge collapsed suddenly and apparently without warning in July 1996, shortly after it had undergone extensive refurbishment. Life in Palau was severely disrupted, even though a ferry connection was established between the islands. The construction of a new bridge was clearly beyond the resources of Palau and had to wait until it could be undertaken with international aid. The interest boundary in this case extended well beyond national boundaries.
In summary, the problem-broadening process should be halted when a further widening of the boundary has only a marginal impact on the original problem statement. The interest boundary can be identified in this way.
The real needs that initiate an engineering project are not always those that are initially perceived. The process of problem widening and the identification of the engineering system as a component in a wider system usually lead to a better understanding of the real needs. In situations where the size and scope and influence of a project are limited, it may be much easier to identify the relevant underlying needs. The attempt to identify underlying needs sometimes moves attention away from purely technical problems towards social issues and political problems, especially when the proposed work is large in magnitude and costly. This is almost inevitable if large sums of public money are to be spent. As the problem-widening and system-widening processes are undertaken, the questions acquire an increasingly political and social flavour and require community input.
When work commences on a new project there is usually a lack of relevant background information. This has to be gathered as early as possible, and before the problem formulation phase is completed. The required information may be scientific and technological, but it may also be non-technical and sociological, legal or political in nature. The data-gathering exercise may require consultation with the community, the use of libraries, the internet, textbooks, and databases.
Each engineering project is designed to bring about some change in the world in which we live. Although the intention is to improve the infrastructure and thereby satisfy some community and individual needs, it is inevitable that there will be side effects. These may be obvious and desirable, but also hidden and undesirable. They may only become evident after a considerable period of time, when the project has been completed and is in operation. In the case of a large-scale project there will usually be a wide range of side effects, some beneficial and some detrimental.
The identification of side effects should begin as early as possible during problem formulation but should continue into the evaluation stages because some side effects will depend on the chosen solution. It is clearly important that the relevant side effects be identified and allowed for when the costs and effectiveness of each alternative approach is evaluated.
It is important in the problem formulation phase to identify the constraints that apply to the problem. Constraints restrict the possible solutions to a problem, and arise in various ways. They may be technical, legal, economic, social, environmental or political in nature. Monetary cost is a constraint that applies in one way or another to every engineering project. Constraints arise if certain side effects are unacceptable or undesirable, such as excessive atmospheric pollution. Technological limitations create other constraints. Legally enforceable industry standards are often the means by which constraints arise in engineering design. Design constraints may be introduced for the different components that make up a system so that they fit together and work in harmony with each other. Constraints can sometimes be quantified as physical limits or as minimum performance requirements which must be achieved.
It is important to have a clear and unambiguous statement of the goals and objectives of any engineering project. This is, in effect, a statement of the problem, and of what is to be achieved. While it is important to clarify the initial problem statement, it can be advantageous not to finalise it until at least some of the background information has been collected. In particular the process of identifying relevant systems as components of larger systems and identifying the problem as part of a larger problem can assist in identifying the objectives.
Furthermore, engineering projects usually do not have just one, but rather a number of different objectives, and some objectives are very likely to conflict with others. The twin requirements of maximum performance and minimum cost are always going to be in conflict. It is always necessary to identify potential conflicts among the objectives.
The goals and objectives of a project are expanded, clarified and quantified through the use of design criteria. Performance requirements and operating conditions are used jointly to specify how the system that is to be created must perform. These are used both in the detailed phases of planning and design, and in the preliminary phases to evaluate and rank alternative approaches and concepts.
Clear and unambiguous statements of goals, objectives, design criteria and performance requirements are particularly important should the completed project or system not reach expectations, with resulting legal dispute. Safety and reliability are further performance requirements which require very careful consideration
The goals and objectives of a project are expanded, clarified and quantified through the measures of effectiveness, which are used in the feasibility study phase of project planning and in the preliminary and the detailed design phases. When a project has more than one objective, one or more measures of effectiveness are needed for each specific objective, and ideally with an overall measure that takes account of the different objectives.
Total cost is often appropriate as the overall measure of effectiveness. This is the case if the various objectives can be stated in terms of equivalent cost. Overall cost is also appropriate if the various objectives can be reformulated as minimum performance requirements, or as constraints that have to be satisfied. Not all situations lend themselves to monetary evaluation. For example, the measures of effectiveness might need to take account of matters such as aesthetics, environmental effects, risk of injury and loss of life.
Question: How would you measure the success of an product from a purely engineering point of
view?
Answer: compare against the requirements and specifications. This is called compliance.
At a higher level, did it bring in profits. At an even higher level, did it solve the wider problem.
Question: How compliant should your product be?
Answer: 100% compliant with the requirements, at least 90% compliant with the specifications.
The various activities occurring within the problem formulation phase may need to be undertaken iteratively. The type of background information that is required becomes progressively clearer after some attempt has been made to identify side effects and constraints and possible approaches. Likewise, some of the constraints and side effects are more easily recognised after some background information has been gathered. It will also be necessary to return to the problem formulation phase as we proceed through the later phases of planning and design.
You have to design an earthquake early warning system. You wish to
base it on the following piece of hardware which acts as a
transducer that
converts seismic activity into an electronic voltage:
Many of these devices will be deployed over a wide area, and will communicate with a data center as
well as any relevant institutions:
There already exists a product that somewhat performs this function. You can look at it for ideas for
your own system:
Question: You have to flesh out this problem into relevant component parts. What parts are there?
Answer: The data acquisition system, the communications network, the data center.
Question: For the data acquision system, data is being dumped into RAM starting from a known address.
The data rate is not that high. How will we collect and transmit this data? Is there any other information we wish to append to this data?
Answer: Shared memory. Put the data into a queue with one thread. In the other thread, filter out relevant data only,
then append any additional information such as GPS location, time stamp, error control coding,...
Question: What language are you going to write this code in?
Answer: C or C++. This is low level programming.
Question: What about the communications network? Will we piggy back off the internet? Have our own
network infrastructure? What type of communication will exist between the data acquisition systems and our data center?
Answer: We could piggy back off the internet. If the terrain is unstable, it is better to have wireless communication.
Security is not a concern, but
error control coding is. If security is a concern, say someone wants to insert false data, then we need to encrypt the
packets. TCP packets are secure and reliable, and since data rate is not high, there is no need for UDP.
Question: What language are you going to write your networking software?
Answer: C or C++ on the data acquisition side. Any
language that supports networking on the data center side.
Question: Your data center is going to require an extensive graphical user interface as well as
the implementation of algorithms for analyzing and presenting the data. What language(s) would the web based
graphical user interface be written in?
Answer: Most likely HTML and JavaScript. Could be in C#. Could be in Java.
Question: What about your algorithms? What language?
Answer: Most likely Python. Python is a great "glue-like" language
that can implement algorithms, interact with the web-interface, and extract packets off our communications network.
C# and Java are good general purpose languages that could perform all these functions, but not as well.
A software system consists of many modules. Learning and practicing modular programming is key to the building
of software systems. The document Software Product Modules
contains typical modules seen in a software product and associated languages for each module. The graphic is repeated here:
For a more advanced look, see the following tutorial on software architecture taken from SED500 (Introduction to Software Engineering):
Software Architecture, a Tutorial (pdf)
and
Software Architecture, a Tutorial (mp4)