Software Engineering: A Methodical Approach (2014)
PART A. Fundamentals
This preliminary division of the course is designed to cover some fundamentals. The objectives are as follows:
· To define and provide a rationale for software engineering as a discipline
· To provide you with a wide perspective of computer software and its varied usefulness and applications
· To discuss different approaches to software acquisition
· To define the job of the software engineer in the organization
· To discuss various tools used by the software engineer
The division consists of two chapters:
· Chapter 1 — Introduction to Software Engineering
· Chapter 2 — The Role of the Software Engineer
Chapter 1. Introduction to Software Engineering
Welcome and congratulations on your entry to this course in software engineering. The fact that you are in this course means that you have covered several fundamental topics in programming, data structures, and perhaps user interface. You have been writing computer programs to solve basic and intermediate-level problems. Now you want to take your learning experience to another level: you want to learn how to design, develop and manage complex software systems (small, medium sized and large), which may consist of tens or hundreds of programs all seamlessly integrated into a coherent whole. You will learn all of these and more in this course, but first, we must start at the beginning. This chapter introduces you to the discipline of software engineering. Topics covered include the following:
· Definitions and Concepts
· The Organization as a System
· Information Levels in the Organization
· Software Life Cycle
· Categories of Software
· Alternate Software Acquisition Approaches
· Software Engineering Paradigms
· Desirable Features of Computer Software
· Summary and Concluding Remarks
1.1 Definitions and Concepts
Computer software affects almost all aspects of human life. A study of the process of software construction and management is therefore integral to any degree in computer science, computer information systems, multimedia technology, or any other related field. Software systems are not created, and do not exist in a vacuum; rather they are typically created by individuals and/or organizations, for use by individuals and/or organizations. We will therefore start by defining a system, defining software, identifying the relationship between the two, and then showing how they both relate to the organization.
1.1.1 System
A system is a set of interacting, interrelated, interdependent components that function as a whole to achieve specific objectives. An effective system must be synergistic. The system usually operates in an environment external to itself. A system may also be defined as the combination of personnel, materials, facilities and equipment working together to convert input into meaningful and needed outputs.
Following are some fundamental principles about systems:
· The components of a system are interrelated and interdependent.
· The system is usually viewed as a whole.
· Every system has specific goals.
· There must be some type of inputs and outputs.
· Processes prescribe the transformation of inputs to outputs.
· Systems exhibit entropy, i.e., tendency to become disorganized.
· Systems must be regulated (planning, feedback and control).
· Every system has subsystems.
· Systems exhibit a tendency to a final state.
As a personal exercise, you are encouraged to identify examples of systems in areas with which you are familiar. A good place to start is the human body.
1.1.2 Software
Software is the combination of program(s), database(s) and documentation in a systemic suite, and with the sole purpose of solving specific system problems and meeting predetermined objectives. Software adds value to the hardware components of a computer system. In fact, without software, a computer is reduced to nothing more than an electronic box of no specific use to most human beings. Also, it should not surprise you that computer software is a special kind of system. This course will teach you how to design, construct and manage such systems.
Software Engineering
Software engineering is the process by which software systems are investigated, planned, modeled, developed, implemented and managed. It also includes the re-engineering of existing systems with a view to improving their role, function, and performance. The ultimate objective is the provision or improvement of desirable conveniences and the enhancement of productivity within the related problem domain.
System transformation may take various paths, some of which may be:
· Improving the internal workings of the system
· Modifying inputs and outputs
· Modifying the goals and objectives of the system
· Redesigning the system
· Designing and developing a new system based on existing problems
Steps in the Analysis Process
Before embarking on any major work in software engineering, a process of research and analysis takes place. This process may be summarized in the following steps:
1. Define the problem.
2. Understand the problem (system) — the interrelationships and interdependencies; have a picture of the variables at work within the system; define the extent of the system (problem).
3. Identify alternate solutions.
4. Examine alternate solutions.
5. Choose the best alternative.
6. Pursue the chosen alternative.
7. Evaluate the impact of the (new/modified) system.
1.2 The Organization as a System
Traditionally, many software systems were created by organizations for use in organizations. To a large extent, this scenario still holds true. For the moment, let us therefore take a look at the organization, in the context of this approach. An organization is a collection of individuals that employ available facilities, resources and equipment to work in pursuit of a predetermined set of objectives. The organization qualifies as a system since it has all the ingredients in the definition of a system: people, facilities, equipment, materials and methods of work.
Every organization has certain functional areas (called divisions, departments, sections, etc.). Typical areas include finance and planning, human resource management (HRM), marketing, production and operations (or the equivalent), technical/manufacturing (or the equivalent). These are usually further divided into departments, units and sub-units. Traditionally, a data processing department/unit would be enlisted as a sub-unit of finance. However, more enlightened organizations are now enlisting information technology (IT) as a functional area at the senior management level, servicing all other areas.
Figure 1-1 shows what a highly summarized organizational chart for a modern organization might look like. In tiny or small organizations, each unit that appears under the president or chief executive officer (CEO) may be a department. In medium-sized and large organizations, each unit under the president or CEO is typically a division, consisting of several departments and/or sections. It should also be noted that you are unlikely to find IT (or the equivalent) at the senior level in many traditional organizations, as managers still struggle with appreciating the scope and role of IT in the organization. However, in more progressive and forward-thinking organizations, you will find that IT is correctly and appropriately positioned at the senior level of the management hierarchy.
Figure 1-1. Typical Organizational Chart
1.2.1 Discussion
Why should IT (or its equivalent) be positioned at the senior level in the organization? If the answer to this question is not immediately obvious to you, it will be by the time you complete this course.
1.3 Information Levels in the Organization
Figure 1-2 shows the information levels in an organization. Information flows vertically as well as horizontally. Vertically, channels are very important. The chart also summarizes the characteristics and activities at each level. Let us examine these a bit closer:
Figure 1-2. Information levels in the organization
1.3.1 Top Management
Activities are strategic and may include:
· Goal setting
· Long term planning
· Expansion or contraction or consolidation
· Merging
· Other strategic issues
For the individuals that operate at this level, there is always an external perspective in the interest of organizational image and interest.
1.3.2 Middle Management
Activities are of a tactical nature and may include:
· Allocation and control of resources
· Medium range planning
· Delegation
· Performance measurement and analysis
For the individuals that operate at this level, subjectivity is rather high — one’s own style is brought into play. There is an internal perspective.
1.3.3 Junior Management and Operational Staff
At the junior management level, one is mainly concerned with:
· Job scheduling
· Checking operational results
· Maintaining discipline and order
Operations at the junior management level are very logical and predictable.
The lowest level is the operational staff. The individuals who work at this level carry out the daily routine activities that keep the organization functioning.
1.3.4 Importance of Information Levels in Software Engineering
The information levels are of importance to the software engineer for two reasons:
· Information gathering and analysis must span the entire organization; therefore communication at the appropriate level is important.
· The information needs vary with each level. An effective software system must meet the need at each level.
Discussion
What kind of information would be required at each level? Propose an integrated software system (showing main subsystems) for a university, a variety store, and a hardware store respectively.
1.3.5 Alternate Organizational Settings
Not all software systems are developed within a structured setting as portrayed in the foregoing discussion. In many cases, software systems are developed by software engineering firms, and marketed to the consuming public. These organizations tend to be more flexible in the way they are structured, often favoring more highly skilled employees, and a more flattened structure. This approach is more fully discussed in chapter 19.
Software systems may also be constructed by amorphously structured organizations. This classification includes individuals operating independently, or as collaborative groups. The open source community is an excellent example of this kind of amorphous operation.
Whatever the circumstance, each software system is only relevant if it fulfills a need that people recognize. It must help solve a problem, and it typically has a period of relevance.
1.4 Software Life Cycle
Every software system has a life cycle — a period over which it is investigated/conceived, designed, development and remains applicable or needed. Various life cycle models have been proposed; we shall examine seven:
· Waterfall Model
· Phased Prototype Model
· Iterative Development Model
· Rapid Prototype Model
· Formal Transformation Model
· Component-Based Model
· Agile Development Model
Irrespective of the model is used, however, a software system passes through the five phases, as depicted in figure 1-3 (related deliverables also shown). These phases constitute the software development life cycle (SDLC).
Figure 1-3. SDLC Phases and Related Deliverables
1.4.1 Waterfall Model
The waterfall model is the traditional approach to software engineering; it may be summarized in the following points:
· It assumes that total knowledge of the requirements of a system can be obtained before its development.
· Each phase of the system life cycle is signed off with the users before advancing to the next phase.
· The process is irreversible - retracting is not allowed until the system is completed.
The model has the following advantages:
· It ensures a comprehensive, functional, well-integrated system.
· It minimizes the level user complaints.
· It ensures user participation (since the user must signoff on each phase).
· It is likely to result in a well-documented system.
The model is not void of major disadvantages:
· System development is likely to take a long time; users may become impatient.
· The requirements of the system may change before the system is completed.
· One may therefore have a well-designed, well-documented system that is not being used, due to its irrelevance.
1.4.2 Phased Prototype Model
This model (also referred to as the evolutionary development model) may be summarized in the following steps:
1. Investigate and fully define the system, identifying the major components.
2. Take a component and model it; then develop and implement it.
3. Obtain user feedback.
4. Revise the model if necessary.
5. If the system is not completed, go back to step 2.
The advantages of phased prototype model are:
· The user gets a feel of the system before its completion.
· Improved user participation over the waterfall model.
· The likelihood of producing an acceptable system is enhanced.
The disadvantages of the phased prototype model include:
· The increased likelihood of a poorly documented system.
· The system may be poorly integrated.
· The system will therefore be more difficult to maintain.
1.4.3 Iterative Development Model
The iterative development model is in some respects a refinement of the phased prototype model. In this approach, the entire life cycle is composed of several iterations. Each iteration is a mini-project in and of itself, consisting of the various lifecycle phases (investigation and analysis, design, construction, implementation, and management). The iterations may be in series or in parallel, but are eventually integrated into a release of the project. The final iteration results in a release of the complete software product.
The advantages of the iterative development model are identical to those of the phased prototype model. However, due to the precautions inherent in the approach, disadvantages (of the phased prototype model) are minimized.
In many respects, the iterative development approach to software construction has been immortalized by the Rational Unified Process (RUP). RUP is an iterative development lifecycle framework that has become a very popular in the software engineering industry. RUP was first introduced by the pioneers of Rational Software — Grady Booch, James Rumbaugh and Ivar Jacobson. Since 2003, the company has been acquired by International Business Machines (IBM). IBM currently markets the Rational product line as one of its prime product lines.
1.4.4 Rapid Prototype Model
Rapid prototyping is a commonly used (perhaps overused) term in software engineering. It refers to the rapid development of software via the use of sophisticated software development tools, typically found in CASE (computer aided software engineering) tools and DBMS (database management system) suites. Another term that keeps flying around is rapid application development (RAD).
The line of distinction of a RAD tool from a CASE tool is not always very clear: in both cases, we are talking about software systems that facilitate development of other software systems by providing among others, features such as:
· Automatic generation of code
· Convenient, user friendly (and typically graphical) user interface
· Executable diagrams
To further blur the distinction, contemporary DBMS suites provide those features also. These tools will be further discussed in chapter 2.
The rapid prototype model may be summarized in the following steps:
· Obtain an idea of the system requirements from user.
· Develop a prototype (possibly under the observation of the user).
· Obtain user feedback.
· Revise if necessary.
One point of clarification: RAD tools, CASE tools, DBMS suites and the like may be employed in any software engineering project, irrespective of the model being followed. Rapid prototyping describes a process, not the tools used.
Rapid prototyping provides us with two significant advantages:
· The system developed is obtained quickly if the first prototype is correct.
· The approach is useful in the design of expert systems as well as small end-user applications.
The main disadvantages of rapid prototyping are the following:
· The system may be poorly documented.
· The system may be difficult to maintain.
· System development could take long if the prototypes are wrong.
1.4.5 Formal Transformation Model
The formal transformation model produces software from mathematical system specifications. These transformations are “correctness preserving” and therefore ensure software quality. A number of formal specification languages have been proposed. However, much to the chagrin of its proponents, software development via this method is not as popular as hoped. Formal methods will be further discussed in chapter 12.
The main advantage of the formal transformation model is the production of provable software i.e. software generated based on sound mathematical principles. This means that the reliability and quality of the software is high.
The model suffers from three haunting disadvantages:
· The approach (of formal methods) is not always relevant to the problem domain.
· The approach uses abstract specifications with which the software engineer must become familiar.
· Due to the use of quite abstract notations, end user participation is not likely to be high, thus violating an essential requirement for software acceptance.
1.4.6 Components-Based Model
The component-based approach produces software by combining tested and proven components from other software products. As the discipline of software engineering becomes more established and more software standards are established, this approach is expected to be more widely used. The approach is commonly called component-based software engineering (CBSE).
The main advantages of CBSE are the following:
· Improvement in the quality and reliability of software
· Software construction can be faster
The main disadvantage of the approach is that like the formal transformation model, it is not always relevant to the problem domain. The reason for this is that software engineering, being a relatively new discipline, has not established enough standards for solving the many and varied software needs that are faced by the world.
1.4.7 Agile Development Model
The agile development model pulls ideas from phased prototyping, iterative development, and rapid prototyping into a model that champions the idea of emphasizing the results of the software engineering effort over the process of getting to the results. The traditional approach of investigation and analysis, design, development, implementation, and management is deemphasized. In contrast, the agile approach emphasizes construction and delivery.
Agile development calls for small, highly talented, highly responsive teams that construct software in small increments, focusing on the essential requirements. The chief architects of the methodology have articulated 12 principles that govern the agile development approach [Beck, 2001]. They are paraphrased below:
1. Place the highest priority on customer satisfaction through early and continuous delivery of valuable software systems.
2. Welcome changing requirements that enhance the customer’s competitive, irrespective of the stage in the development.
3. Deliver working software frequently, and within a short timeframe.
4. Get the business people and the software developers to work together on a consistent basis throughout the project.
5. Build projects around motivated individuals. Give them the required resources and trust them to get the job done.
6. The most efficient and effective method of communication within a software engineering team is face-to-face conversation.
7. The primary measure of progress and success is a working software system or component.
8. The agile development process promotes sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. There should be continuous attention to technical excellence and good design.
10.There should be great emphasis on simplicity as an essential means of maximizing the amount of work not done.
11.The best architectures, requirements, and designs emerge from self-organizing teams.
12.The software engineering team should periodically reflect on how to become more effective, and then refine its behavior accordingly.
The advantages of agile development are similar to those of phased prototyping:
· The user gets a version of the required software system in the shortest possible time.
· By merging business personnel and software developer in a single project, there is improved user participation.
· The likelihood of producing an acceptable system is enhanced.
Like the advantages, the disadvantages of the agile development model are comparable to those of the phased prototyping model:
· There is an increased likelihood of a poorly documented system. In fact, some extreme proponents of agile development go as far as to deemphasize the importance of software documentation.
· The system may be poorly integrated.
· A system that is poorly designed, documented, and poorly integrated is likely to be more difficult to maintain, thus increasing the said cost that agile development seeks to control.
1.5 Categories of Software
Software engineering is a very wide, variegated field, constrained only by one’s own imaginations and creativity. There are, however, some observable categories of software. Figure 1-4 provides a list of common software categories. Most of the software products that you are likely to use or be involved with fall into one or more of these categories.
Figure 1-4. Common Software Categories
1.6 Alternate Software Acquisition Approaches
Software may be acquired by any of the following approaches, each with its advantages and challenges:
· Traditional waterfall approach (in-house or via contracted work)
· Prototyping (phased or rapid, in-house or via contracted work)
· Iterative development (in-house or via contracted work)
· Assembly from re-usable components (in-house or via contracted work)
· Formal transformation (in-house or via contracted work)
· Agile development (in-house or via contracted work)
· Customizing an application software package
· End-user development
· Outsourcing
Whatever the acquisition approach that is employed, a software engineering objective of paramount importance is the production of software that has a significantly greater value than its cost. This is achieved by packing quality in the product from the outset — a principle that is emphasized throughout the text.
1.6.1 Discussion
As a personal exercise, determine what scenario(s) would warrant each approach.
1.7 Software Engineering Paradigms
There are two competing paradigms of software construction: the (traditional) function-oriented (FO) approach and the (more contemporary) object-oriented (OO) approach. The two approaches, though sometimes divergent, are not mutually exclusive — an experienced software engineer can design and construct software systems using aspects of both approaches. This leads to a third alternative — the hybrid approach — which ideally borrows the strong points from both approaches, while avoiding the vulnerable points in either (see [Foster, 2010]).
This course pursues a balance between the object oriented paradigm and the function oriented paradigm, with a strong focus on the fundamentals, and an evident bias to the object-oriented paradigm. A full treatment of the object-oriented approach is (best) treated in another course —object-oriented software engineering (OOSE) or object-oriented methodologies (OOM). However, in keeping with the bias, the appendices contain useful additional information on OOM.
1.8 Desirable Features of Computer Software
The following are some desirable features of computer software:
· Maintainability: How easily maintained is the software? This will depend on the quality of the design as well as the documentation.
· Documentation: How well documented is the system?
· Efficiency: How efficiently are certain core operations carried out? Of importance are the response time and the system throughput.
· User Friendliness: How well designed is the user interface? How easy is it to learn and use the system?
· Compatibility: with existing software products.
· Security: Are there mechanisms to protect and promote confidentiality and proper access control?
· Integrity: What is the quality of data validation methods?
· Reliability: Will the software perform according to requirements at all times?
· Growth potential: What is the storage capacity? What is the capacity for growth in data storage?
· Functionality and Flexibility: Does the software provide the essential functional features required for the problem domain? Are there alternate ways of doing things?
· Differentiation: What is unique about the software?
· Adaptability: How well are unanticipated situations handled?
· Productivity: How will productivity be affected by the software system?
· Comprehensive Coverage: Is the problem comprehensively and appropriately addressed?
These features are often referred to as software quality factors and for good reasons, since they affect the quality of the software products. In this course, you will learn how to research, plan, design, and construct software of a high quality. You will do so in a deliberately methodical manner. As such, we will revisit these quality factors later, and show how they can be used to guide the software engineering process.
1.9 Summary and Concluding Remarks
Let us summarize what has been covered in this chapter:
· A system is a set of interacting, interrelated, interdependent components that function together as a whole to achieve specific objectives.
· Software is the combination of program(s), database(s) and documentation in a systemic suite, with the sole purpose of solving specific system problems and meeting predetermined objectives.
· Software engineering is the process by which an information system or software is investigated, planned, modeled, developed, implemented and managed.
· The organization is a complex system consisting of personnel, facilities, equipments, materials and methods.
· Software systems are created specifically for organizational usage and benefits.
· Every software system has a life cycle — a period over which it is investigated/conceived, designed, development and remains applicable or needed. Various life cycle models have been proposed; this chapter examined the following seven models: waterfall, phased prototyping, iterative development, rapid prototyping, formal transformation, component-based development, and agile development.
· Irrespective of the life cycle model employed, computer software goes through the phases of investigation and analysis, design, development, implementation, and management. These phases are referred to as the software development life cycle (SDLC).
· Two paradigms of software construction are the function-oriented (FO) approach and the object-oriented (OO) approach.
· Among the desirable features of computer software are the following: maintainability, documentation, efficiency, user friendliness, compatibility, security, integrity, reliability, growth potential, functionality and flexibility, differentiation, adaptability, productivity, and comprehensive coverage.
So now you have an academic knowledge of what is meant by software engineering. As you will soon discover, this is not enough. To excel in this field, you will need experiential knowledge as well. But you have made an important start in exploring this exciting field. Much more could be said in this introductory chapter. If you are comfortable with the material presented and want to delve deeper into the OO paradigm for software engineering, please refer to appendix 1, appendix 2 and appendix 3. The next chapter will discuss the role of the software engineer in the organization.
1.10 Review Questions
1. Give definitions of:
· A system
· Computer software
· Software engineering
2. Explain how software engineering relates to the management of an organization.
3. Develop an organization chart for an organization that you are familiar with. Analyze the chart and propose a set of interrelated software systems that may be used in helping the organization to achieve its objectives.
4. Why should a software engineer be cognizant of the information levels in an organization?
5. What is the software development life cycle? Explain its significance.
6. Discuss the seven life cycle models covered in the chapter. For each model:
· Describe the basic approach
· Identify the advantages
· Identify the disadvantages
· Describe a scenario that would warrant the use of this approach
7. Identify ten major categories of computer software. For each category, identify a scenario that would warrant application of such a category of software.
8. Discuss some desirable features of computer software.
9. Write a paper on the importance of software engineering, and your expectations for the future.
1.11 References and/or Recommended Readings
[Beck, 2001] Beck, Kent, et. al. Manifesto for Agile Software Development. 2001. http://www.agilemanifesto.org/ (accessed June 2009).
[Bruegge, 2004] Bruegge, Bernd and Allen H. Dutoit. Object-Oriented Software Engineering 2nd ed. Upper Saddle River, NJ: Prentice Hall, 2004. See chapter 1.
[Foster, 2010] Foster, Elvis C. with Shripad Godbole. Database Systems: A Pragmatic Approach. Bloomington, IN: Xlibris Publishing, 2010. See chapter 23.
[Harris, 1995] Harris, David. Systems Analysis and Design: A Project Approach. Fort Worth, TX: Dryden Press, 1995. See chapters 1 and 2.
[Kendall, 2005] Kendall, Kenneth E. and Julia E. Kendall. Systems Analysis and Design 6th ed. Upper Saddle River, NJ: Prentice Hall, 2005. See chapters 1and 2.
[Loudon, 1994] Laudon, Kenneth C. and Jane P. Laudon. Management Information Systems 4th ed. Eaglewood Cliffs, NJ: Prentice Hall, 1994. See chapters 1 – 4, 12, 15, 16, 17, 18.
[Long, 1989] Long, Larry. Management Information Systems. Eaglewood Cliffs, NJ: Prentice Hall, 1989. See chapters 1–3.
[Maciaszek, 2005] Maciaszek, Leszek A. and Bruce Lee Long. Practical Software Engineering. Boston, MA: Addison-Wesley, 2005. See chapter 1.
[Peters, 2000] Peters, James F. and Witold Pedrycz. Software Engineering: An Engineering Approach. New York, NY: John Wiley & Sons, 2000. See chapters 1 and 2.
[Pfleeger, 2006] Pfleeger, Shari Lawrence. Software Engineering Theory and Practice 3rd ed. Upper Saddle River, NJ: Prentice Hall, 2006. See chapters 1and 2.
[Pressman, 2005] Pressman, Roger. Software Engineering: A Practitioner’s Approach 6th ed. Crawfordsville, IN: McGraw-Hill, 2005. See chapters 1–3.
[Schach, 2005] Schach, Stephen R. Object-Oriented and Classical Software Engineering 6th ed. Boston, MA: McGraw-Hill, 2005. See chapters 1–3.
[Sommerville, 2006] Sommerville, Ian. Software Engineering 8th ed. Reading, MA: Addison-Wesley, 2006. See chapters 1-3.
[Spence, 2004] Spence, Ian and Kurt Bittner. Managing Iterative Software Development with Use Cases. IBM, June 2004. http://www.ibm.com/developerworks/rational/library/5093.html (accessed December 2009).
[Van Vliet, 2000] Van Vliet, Hans. Software Engineering 2nd ed. New York, NY: John Wiley & Sons, 2000. See chapters 1 and 2.