Software Engineering: A Methodical Approach (2014)
PART D. Software Development
This relatively short division of the text involves three chapters:
· Chapter 14 — Software Development Issues
· Chapter 15 — Human Resource Management
· Chapter 16 — Software Economics
The brevity of this division is by no means an indication of the level of importance to be given to software development. To the contrary, software construction remains a critical aspect of the software engineering experience; after all, without development, there is no software product.
Traditionally, software engineering projects would dedicate roughly 20 percent of the time to requirements specification and design specification, and the rest of the time to development. As emphasized throughout the text, this has proven to be an inappropriate and imprudent approach to the discipline of software engineering. Rightly so, much focus has been shifted to the earlier phases of the SDLC, in an attempt to have a more balanced approach, thus leading to the production of higher quality software. This course embraces that shift. Software construction then, ought to be a rewarding, exciting, enjoyable experience of building a product that was carefully, thoughtfully, skillfully and methodically planned. It should not be characterized by guesswork and failure, but confidence and anticipation. After all, you are merely implementing a plan that passed through the rigors of investigation, analysis, design and several iterations of refinement.
It is against this background that you are invited to embark on the software construction experience. Good software construction requires the observance of some management techniques that have either been discussed in previous chapters (for example PERT/CPM), or are too involved to be thoroughly discussed in this course (for example human resource management and team motivation). It also presumes the mastery of fundamental programming skills. Nonetheless, the chapters pull the critical pieces together to provide you with a comprehensive perspective.
Chapter 14. Software Development Issues
This chapter discusses important software development issues that are critical to the successful construction of a top quality software product. It proceeds on the presumption that appropriate steps were taken in the earlier phases of the software engineering experience (namely investigation, analysis and design), and under the following subheadings:
· Introduction
· Standards and Quality Assurance
· Management of Targets and Financial Resources
· Leadership and Motivation
· Planning of the Implementation Strategy
· Summary and Concluding Remarks
14.1 Introduction
If enough thought and planning were put in the design phase, software development should proceed smoothly. In fact, for the meticulous and keen software engineer, software development is fun; it represents the beginning of seeing the fruition of diligent work, invested up front, in the investigation, planning and design of the software. Indeed, the following statement is worth remembering.
Software development may employ any of the life cycle strategies discussed in chapter 1. In the interest of clarity, these strategies are listed and clarified (in the context of development) below:
· Waterfall Model: Keep writing code until the software system is finished.
· Phased Prototype Model: Develop the software system chunk by chunk.
· Iterative Development Model: Develop the software system iteration by iteration.
· Rapid Prototype Model: Take a swipe at developing a working model of the software system and hope for the best; then use user feedback to refine.
· Formal Transformation Model: Generate provable code for the software system.
· Component-based Model: Develop the software system by integrating used and tested components; write code only for the missing pieces and for integrating the components.
· Agile Development Model: Merge the ideas of phased prototyping and iterative development, focusing on the construction and delivery of a product with the minimum required essentials features.
During software development, a team of software developers uses a set of software development tools to write and/or generate code for the software system, based on the design specification. The design specification is used an input to this phase of the SDLC; the output from this phase is the actual software product (including its documentation).
Management of the project is of paramount importance during this phase. Things may deviate from actual projections and it is here that the management skills of the project manager will be challenged. Accordingly, the project manager will need to exhibit good project management skills; he/she will also need to be creative. Recall that chapter 8 discussed tools such as PERT, CPM, and project management software systems. We will focus on the other related issues in this and the next two chapters.
14.2 Standards and Quality Assurance
In order to ensure that the quality of the software constructed is acceptable, the project manager as well as the software engineers must be concerned about standards and quality. Software quality affects how end users will relate to the product, the level of acceptance the product will receive in the organization, and how the product will perform in the marketplace. As such, the following statement is worth remembering:
With respect to standards and quality assurance, three issues are worth mentioning:
· The relationship between quality and standards
· The software quality factors
· The quality evaluation
14.2.1 The Relationship between Quality and Standards
During software development, many of the issues addressed in chapter 9 on software development standards are applicable. To review, the following issues will be of importance:
· Naming of database and non-database objects
· Naming of operations
· Programming standards
· User Interface standards
· Documentation standards
· Database design standards
In this regard, the project manager must be knowledgeable and preferably an expert in order to effectively manage the software engineering project. In complex situations he/she may have to lead and manage by example.
Quality assurance (QA) involves the process of ensuring that the software meets the requirements and design specifications, and conforms to established standards. QA is applicable to all aspects of business. Figure 14-1 defines a procedure for maintaining a high software quality during a software engineering project. Essentially, the procedure establishes a loop between software development and assessment against established standards and requirements. Looping continues until the standards and requirements are met.
Figure 14-1. Procedure for Maintaining Software Quality
In business, a concept that has become very popular since the 1990s, and has remained so, is total quality management (TQM). A full discussion of TQM is beyond the scope of this course. Suffice it to say, TQM is a comprehensive philosophy that encompasses all aspects of the organization, and all management functions. Two sound principles of TQM are worth stating here:
· Do it right the first time
· Do it again
The first statement implies that the programmer or software engineer should spend some time to convince himself/herself that a program or module or system works before submitting it for QA evaluation. The QA evaluation then becomes a means of fine-tuning the system rather than identification of major rework.
The second statement implies that the process of proliferation of good standards, models and methodologies should be pursued. As a practical example, a programmer should spend some time to get his/her first ADD operation correctly. This can then be used as the basis for other ADD operations.
Quality should be proactive rather than reactive. Put another way, quality should seek to avoid errors, rather than respond to them. Quality should focus on all phases of the system life cycle equally rather than the maintenance phase primarily. Quality must characterize all aspects of the software, not just some aspects.
Quality standards must be effectively communicated to all relevant levels of the organization. In particular, the project team must be aware of such requirements. Here is a rhetorical question worth remembering:
14.2.2 Software Quality Factors
The software quality factors were first introduced in chapter 1; they were also mentioned in chapter 3, and again in chapter 9. They cannot be overemphasized; they affect the success or failure of the software. As a software engineer, when you design software, you must design with these factors constantly in mind. These factors, along with your software standards, if observed during construction, will ensure a high quality in the final product. In the interest of ease of reference, the quality factors are repeated here:
14.2.3 Quality Assurance Evaluation
Operations comprising the software should be tested singly as well as collectively. A QA evaluation (traditionally referred to as a structured walk-through) is a comprehensive test of a software system, or component thereof. The evaluation may be done at different levels — for an operation, a group or related operations (a module), a subsystem, or the entire software system.
Important parties to be involved in a major QA evaluation include the following:
· Project manager
· Software engineer or programmer responsible for the component
· A principal user
· Someone to take notes (if not the software engineer)
In some circumstances, a tester or a software engineer, prior to a QA evaluation with all the relevant parties, may test the component. The objective of the QA evaluation is to verify that the operation, module, subsystem, or system meets user requirements and conforms to QA standards. Usually, a standard form is developed to record the result of such evaluations. Bear in mind, however, that the forms may be in hard copy, or stored on the computer. Figure 14-2 illustrates what an evaluation form might look like.
Figure 14-2. Illustrative QA Evaluation Form
14.3 Management of Targets and Financial Resources
The creativity and management skills of the project manager are challenged most strongly during software development. The critical question to address is, how can resources be allocated in order to ensure that targets are met? PERT/CPM is project management technique that is commonly used (review chapter 8).
Two additional areas of concern are:
· Budget and expenditure
· The value of the software system
14.3.1 Managing Budget and Expenditure
Budget management is an important aspect of software development. There are two components to budget management: planning the budget and monitoring the expenditure. The budget planning would have been completed from the early (planning) stages of the project. What is required during development is monitoring of the targets, the resources and the expenditure. Following is a summary of what is required in each aspect. However, please note that a comprehensive treatment of budget management is beyond the scope of this course (for additional information, see recommended reading [Morse, 2000]).
Budget Preparation
The budget typically spans a fiscal year. However it might be broken down on quarterly basis or a monthly basis. The budget contains summery items and line items that make up the summary items. The summary items and some of the line items are typically predetermined, based on the organization’s chart of accounts.
The budget may also be split into broad categories of expenditure items, for instance capital expenditures and recurrent expenditures. Capital expenditures relate to investments in fixed assets and/or infrastructure. Recurrent expenditures relate to operational issues (such as salaries, stationary, fuel, heating, electricity, transportation, etc.)
Figure 14-3 illustrates how a budget might be composed. Please note:
1. Each summary item (e.g. Network Upgrade) would have associated detail line items that may be part of the main document, or included as an appendage. The details will show how each summary amount was arrived at.
2. In some instances, supporting documentation (such as quotations from vendors) may be required.
Figure 14-3. Example of a Budget
Since one’s budget will ultimately affect one’s ability to pursue the projects of intent, it is imperative that the budget be comprehensive. Also, to avoid embarrassments due to budget overruns, it is always better to over-estimate rather than under-estimate expenditure.
Budget Monitoring
Once a voted budget is in place, the project manager will be aware of this. Software development should proceed according to the budget that is in vogue; ensuring this is the responsibility of the project manager. Issues such as project crashing (review chapter 8) or recasting of certain targets may become relevant as the project proceeds. However, note that recasting of targets reflects poorly on the project management, and must only be considered when it is clear that the circumstances warranting these changes are beyond the control of the project manager.
14.3.2 Managing Software Cost and Value
Yet another significant consideration is the actual costing of the software product. This is particularly important if the product is to be marketed, or its value included as part of the organization’s capital assets. One popular model for estimating software cost is the COCOMO model. This will be discussed in more detail in chapter 16. The basic proposal of the model is that software cost is a function of software size (measured as source code instructions). Of course, other algorithmic cost models have been proposed. Typically, software cost is influenced by the following factors:
· Size (measured in lines of code)
· Complexity (determined by the number of complex calculations and algorithms involved)
· Value added to the organization that acquires the software
· Consumer demand for the product
14.4 Leadership and Motivation
A study of leadership and motivation belongs more appropriately to the field of organizational theory and behavior (OTB) and cannot be comprehensively covered in this course. Suffice is to say that the project manager (who might very well be a software engineer) must be appropriately prepared (academically and experientially) to offer effective leadership. He/she must be familiar with various leadership and motivational theories. In passing, a few important points will be stated.
The project manager should know when to apply certain principles and theories of management. Some of the paradigms have been listed in Figure 14-4. These will be clarified in the upcoming chapter.
Figure 14-4. Management Styles
The ability to adjust to situations and manage accordingly is called situational (contingency) management; this is the preferred approach. The project manager must be able to identify the abilities, needs, and perceived values of members of his/her team and assign activities that will help the respective individuals to realize those needs. This will ensure optimum productivity.
The project manager must be a good motivator. The project manager’s most valuable resource is his/her human resource. If you have a team of individuals who are perpetually unmotivated, that team will not achieve much. Software engineering is serious business and must be taken as such.
A full discussion of motivation theory is beyond the scope of this course. Figure 14-5 provides a brief summary of some prominent motivation theories. Since the software engineer may be often called upon to lead project teams, it is in his/her interest to be cognizant of these theories, in order to be effective at project management.
Figure 14-5. Popular Motivation Theories
14.5 Planning of Implementation Strategy
Plans for the implementation must be made and finalized well ahead of the implementation time. This matter will be discussed in chapter 17. The main implementation issues to be considered are
· Operating environment
· Installation
· Code conversion
· Training
· Change over
· Marketing
As you will soon see, these issues could influence the success or failure of the software product in the organization and/or marketplace.
14.6 Summary and Concluding Remarks
Here is a summary of what has been discussed in this chapter:
· If enough thought and planning were invested in the design of the software, actual construction will be an enjoyable, exciting, and rewarding experience. Prudent project management will also be required of the project manager (who is likely to be a lead software engineer) during this period.
· Excellent software quality is not a miracle; it will not just happen, if it was not deliberately built into the design, and consistently pursued during development and implementation. Procedures for building quality in the software product must be clearly outlined and followed.
· The QA evaluation is used to ensure that established software standards are upheld during the development process.
· During software development, resources, targets and expenditure must be carefully managed to ensure that the project meets its deadlines.
· Leadership and motivation is also a critical factor during software developed. Ideally, the project manager must be an excellent leader and motivator.
· The implementation strategy for the software system must be planned well ahead of the completion of the software development.
The matter of leadership and motivation is extremely important in a software engineering project. For this reason, it is given a bit more attention in the upcoming chapter.
14.7 Review Questions
1. What are the critical issues to be managed during the development phase of a software engineering project?
2. Explain how software standards relate to quality assurance. Outline a procedure for maintaining software quality.
3. Discuss the QA evaluation exercise and propose an instrument for use during this experience.
4. Describe a technique for managing resources, targets, budget and expenditure during software development.
5. How important is leadership during a software engineering project? Explain.
14.8 References and/or Recommended Readings
[Boehm et. al., 1997] Boehm, Barry W., C. Abts, B. Clark, and S. Devnani-Chulani. COCOMO II Model Definition Manual. Los Angeles, CA: University of Southern California, 1997.
[Kendall, 2005] Kendall, Kenneth E. and Julia E. Kendall. Systems Analysis and Design 6th ed. Upper Saddle River, NJ: Prentice Hall, 2005. See chapter 16.
[Lewis, 1993] Lewis, Phillip V. Managing Human Relations. Boston, MA: Kent Publishing, 1993.
[Morse, 2000] Morse, Wayne, James Davis and Al L. Hartgraves. Management Accounting: A Strategic Approach. Cincinnati, OH: South-Western College Publishing, 2000. See chapter 11.
[Peters, 2000] Peters, James F. and Witold Pedrycz. Software Engineering: An Engineering Approach. New York, NY: John Wiley & Sons, 2000. See chapters 12 - 14.
[Pfleeger, 2006] Pfleeger, Shari Lawrence. Software Engineering Theory and Practice 3rd ed. Upper Saddle River, NJ: Prentice Hall, 2006. See chapters 7 - 9.
[Pressman, 2005] Pressman, Roger. Software Engineering: A Practitioner’s Approach 6th ed. Crawfordsville, IN: McGraw-Hill, 2005. See chapter 26.
[Sommerville, 2006] Sommerville, Ian. Software Engineering 8th ed. Boston, MA: Addison-Wesley, 2006. See chapters 17-23.
[Van Vliet, 2000] Van Vliet, Hans. Software Engineering: Principles and Practice. New York, NY: John Wiley & Sons, 2000. See chapter 13.