In this summary, Software Engineering Management is approached from the objective or end-result point-of-view. Thus, the emphasis is on the solution, where the solution is the set of ideas the implementation of which impacts at least one part of the problem positively. A solution worth considering is one whose positive contributions to the requirements outweighs its negative ones. This implies that : known requirements needed to be specified clearly and unambiguously, all positive contributions of the solution to quality requirements needed to be known, negative side-effects of the solution on the quality requirements needed to be known and all resource consumption in relation to the budget needed to be understood.
There are differences between functions, attributes and solutions. Functional goals are a simple list of what we want in the future, they are absolute requirements which have only one future state - true or false. Attribute goals are variable (in time) and negotiable (depends on what it costs to get it) numeric dimensions which the functions will possess. Attribute goals refer to requirements which can be expressed on scales of measurement. The solutions are the an swers to the questions posed by the function and attribute goals, they are ideas which, if implemented, will impact the future goals. Solutions should never be specified or implied in a goal ststement, unless they really are high-priority goal itself. Management must avoid the imposition of solution ideas, and instead concentrate on goal-priority specification. The best solution, the one that should be adopted, is the one with the best overall match with the attribute requirement specification at the planned levels.
Impact estimation, in which how far a solution contributes to the required attributes, fills the dangerous gap between good intentions (attribute specifications) and unpleasant realities (acceptability tests for the attributes). It gives early warning s ignals about possible future system failure or bad solutiojn economy. Even if it is not known for sure, a rough estimate can be made and improved upon later. And uncertainty must certainly be stated in no uncertain terms. The contribution of particular solution-component towards our goals, must therefore often be written in the form of uncertainty estimates or ranges of possible values. Uncertainty estimates are not required when the estimate is not controversial or significant. The comparative analysis of complex alternatives is a common problem in management decision making. The solution comparison method is designed to help resolve this problem - to enable one to choose the "best" option from among a number of apparently satisfactory ones.
The inspection method is a powerful partner for getting an organization to evaluate the contents of all design and code documentation at the earliest possible stages. The inspection method is the most effective quality control method for software specification documentation we know about. While it might appear time and cost consuming to implement, the value of catching errors early has been proven to far outweigh the cost of doing the inpection.
The implementation of a solution which is based on plans containing estimates, approximations and uncertainties, involves risk. And if one do not actively attack the risks, they will actively attack you. Knowing that there is a risk, and knowing even approximately what the level of that risk is, is a sign of professional competence. The real professional is one who knows the risks, their degree, their causes, and the action necessary to counter them, and shares this knowledge with his colleagues and clients. Risk prevention is more cost-effective than risk detection.
Never make promises you cannot keep, no matter what the pressure. If you do make any promises, make them yourself, and make them in writing. When you make a promise, include your estimate of how much deviation could occur for reasons outside of your control, for reasons within your control, and for reasons others in the company can control. When something happens during the project that you did not foresee, which increases deviation from planned risk, immediately raise the issue, in writing, with your constructive suggestions as to how to deal with it. If you suspect someone else - your boss or client - of assuming you have made promises, then take the time to disclaim them, and repeat the promises you have made, if any, in writing. When indicating possible deviation, make a list of the possible causes of deviation, as well as a list of the actions you could take to control those risks. Hang the following sign near your desk : IF YOU HAVEN'T GOT IT IN WRITING FROM ME, I DIDN'T PROMISE IT. The degree of risk, and its causes must never be hidden from decision-makers. If one don't ask for risk information, one is asking for trouble. The "best imaginable" can be a reality, if you are willing to risk or sacrifice any other planned attributes. Uncertainty in a technical project is half technical and half motivational, but with good enough motivation, uncertainty will not be allowed to lead to problems. Theoretical estimation is as accurate as our oversimplified estimation models backed by obsolete historical data. The real thing is a somewhat more reliable indicator.
The evolutionary delivery method is based on the following simple principle : deliver something to a real end-user, measure the added-value to the user in all critical dimensions, and adjust both design and objectives based on observed realities. Evolutionary delivery consists of a collection of many concepts including : multi-objective driven; early, frequent iteration; complete analysis, design, build and test in each step; user orientation; systems approach, not merely algorithm orientation; open-end ed basic systems architecture; and result orientation, not software development process orientation. The principles of evolutionary delivery are : all large projects are capable of being divided into many useful partial result steps; the only critical step is the next one; evolutionary steps should be delicered on the principle of "the juiciest one next"; Result delicery (not the construction activity) is the only point; open-ended architecture should be at the base, otherwise the step transition cost wi ll be unnecessary high; any step sequence you plan will be changed by the facts you learn as you deliver the early steps; maximizing the real progress towards the specified goals is the only measure of successful evolutionary delivery; the evolutionary pr ocess can lead to change of your techincal design solutions, or change of your lower-priority requirements so that you can reach your higher-priority goals instead; you don't need to recreate a minimum working system before making your first improvements, if you use an already existing systems to start with; and if evolutionary delivery doesn't work, then you haven't been doing it properly.
The end-users themselves, not the producers, should be the final judge of productivity in the sense of software quality. The more precisely you can specify and measure your particular concept of productivity, the more likely you are to get practical and economic control over it. Productivity must be defined in terms of a number of different and conflicting attributes which lead to the desired results. The most dramatic productivity changes results from radical change to the solution architecture, rath er than just working harder or more effectively. You can usually re-engineer the solution so that it will fit within your most limited resources. This may be easier than finding ways to inmprove the productivity of people working on the current solution . Frequent and early result-measurement during development will prevent irrelevant production.
An estimation or control technique must reflect a large number of complex and dynamic factors. A diversity of approaches will be necessary throughout the development and maintenance process, and throughout the system lifetime, to ensure that you keep on getting what you really need. Rethink the deadline given you, it may not be real. If the dealine is critical and seems impossible to reach, don't be afraid to change the solution. If dealines are critical, make maximum use of existing systems and "known technology". Avoid research-into-unknowns during your project.
Adapted from "PRINCIPLES OF SOFTWARE ENGINEERING MANAGEMENT" by TOM GILB.