Software Engineering: A Methodical Approach (2014)
PART A. Fundamentals
Chapter 2. The Role of the Software Engineer
This second chapter will examine the role, responsibilities, functions and characteristics of the software engineer in the organization. The following will be discussed:
· Historical Role
· Modern Role of the Software Engineer
· Job Description of the Software Engineer
· Tools Used by the Software Engineer
· Management Issues With Which the Software Engineer Must be Familiar
· Summary and Concluding Remarks
2.1 Historical Role
Historically, most systems were manual and coordinated by a systems and procedure analyst with responsibilities such as:
· Forms design and record management
· Analysis, design and management of manual systems
· Report distribution analysis
· Work measurement and specification
· Development and maintenance of procedure manuals
The systems and procedure analyst was usually attached to the Finance Department. Most systems were accounting oriented. This created an imbalance. A second difficulty was the collation of information from various departments.
The arrival of computer technology triggered several changes and brought several advantages:
· A vast amount of data could be collected and stored.
· Inherent validation checks could ensure data accuracy.
· The response was fast.
· There was significant reduction of manual effort, redundancies and data security problems.
2.2 Modern Role of the Software Engineer
In addition to the historical roles, the software engineer (SE) takes on additional responsibilities, some of which are mentioned here:
· The software engineer acts as a consultant to the organization.
· The software engineer is the supporting expert on system design, development, implementation and maintenance.
· He/She is the change agent in the organization, lobbying for and effecting system enhancements (manual and automated; strategic and functional).
· The software engineer acts as a project leader on the development or modification of systems.
The software engineer acts as a software designer and developer (especially in developing countries or other environments where resources are scarce).
The contemporary trend reflects a bias to the title of software engineer instead of the traditional systems analyst (SA). Software engineer is more accurate as it spans the whole software development life cycle. However, many organizations tend to stick to the traditional. Where both titles are used in the same organization, the SA usually operates upper phases of SDLC, while the software engineer operates in the lower phases; some overlap typically takes place in the area of software design.
2.3 Job Description of the Software Engineer
If you are interviewed for, or employed as a software engineer, one of the first pieces of document you will receive is a job description. Each organization has its own standards as to how job descriptions are written. However, generally speaking, the job description will have the following salient components:
· Heading: An organizational heading followed by a departmental heading.
· Summary: A summary of what the job entails.
· Core Functions: A list of core functions and/or responsibilities of the job. This is further elucidated below.
· Desirable Qualities: A section describing the desirable qualities of the incumbent. This is further elucidated below.
· Authority: A section that outlines the authority associated with the job.
· Job Specification: A section that describes reporting relationship and other related information about the job.
Figure 2-1 provides an illustration of a job description of a software engineer. It includes all the essential ingredients mentioned above. The next two subsections further provide content guidelines for the core functions of a software engineer, and the desirable qualities of the incumbent.
Figure 2-1. Sample Job Description for a Software Engineer
2.3.1 Core Functions of the Software Engineer
Some core functions of the software engineer are as follows:
· Investigates and defines software system problems, and makes proposals for their solution.
· Carries out detailed feasibility analysis and system specification.
· Plays a critical role in the design and development of software systems in the organization.
· Participates in the process of hardware/software selection for the organization.
· Participates in the definition of software engineering standards for the organization.
· Performs as project leader according to assignment from his superior.
· Conducts system enhancements as required.
· Keeps abreast of current technological developments and trends, and ensures that the organization is strategically positioned.
· Plays a crucial role in the development and maintenance of system and user documentation.
· Plays a crucial role in the training of staff.
· Ensures the safety of all information technology (IT) related resources.
2.3.2 Desirable Qualities of the Software Engineer
Among the required qualities of the software engineer are the following:
· Excellent communication skills
· Pleasant personality
· Tolerant and businesslike
· Experienced in various computer platforms, applications and software
· Wide experience in (appreciation of) business administration
· Able to effectively and efficiently assimilate large volumes of information
· Imaginative and perceptive
· Able to understand complex problems
· A good sales person of ideas
2.4 Tools used by the Software Engineer
Traditionally, the tools the software engineer uses in performing include:
· Coding Systems
· Forms Design
· Data Analysis Charts
· Decision Tables and Decision Trees
· Flow Charts and Diagrams
· Other Creative Technical Documents and Modeling Techniques
· Software Planning and Development Tools
Additionally, object-oriented software engineering (OOSE), also referred to as object-oriented methodologies (OOM), provides other standards, conventions and tools. This course covers the main OO design techniques and methodologies; however a more detailed treatment can be obtained from a course in OOSE or OOM (see the appendices). Flow charts, diagrams and decision tables/trees are covered in lectures 5 and 6 respectively. The other mentioned tools will be briefly discussed here.
2.4.1 Coding Systems
A code is a group of characters used to identify an item of data and show its relationship to other similar items. It is a compact way of defining a specific item or entity. Coding systems are particularly useful during forms design and database design (to be discussed in chapter 10). Benefits of a proper coding system include:
· Reduction of storage information
· Easy identification and recollection
· Easy classification of data
Desirable Features of a Coding System
A coding system must exhibit some of the following features:
· Uniqueness: The code must give specificity to different items.
· Purpose: The code must serve a useful purpose (e.g. comparison or location).
· Compactness: The code must not be too bulky.
· Meaningful: The code must be meaningful. The code can relate to shape, size, location, type, or other features of items represented.
· Self-checking: The code may be self-checking, utilizing a mathematically calculated check digit as part of the code to ensure validity.
· Expandable: The code must be expandable; it must be easy to add new blocks of items.
Types of Coding Systems
There are six common types of coding systems as summarized below. Bear in mind however, that in many practical cases, coding types are combined to form the desired coding system.
1. Simple Sequence
· Numbers are assigned consecutively, e.g.1,2,3,…
· The main advantage of the approach is that an unlimited number of items can be stored.
· The main drawback is that little or no information conveyed about items.
2. Block Sequence
· Blocks of consecutive numbers identify groups of similar items.
· The main advantage of this approach is that more information is conveyed about the items.
· The main drawback is that it is not always possible to maintain sequencing in each block.
3. Group Classification
· This approach involves a major, intermediate and minor classification of items by ordering or digits. A good example is the US zip code.
· The main advantage of the approach is that data can be subdivided.
· One possible drawback is that groups can become quite large.
4. Significant Digit
· For this type of code, a digit is assigned to denote a physical characteristic of the item.
· The main advantage of the approach is that it aids physical identification of the items.
· Except for a few simple scenarios, the approach is inadequate to be used on its own. For this reason, it is often combined with another type of coding.
5. Alphabetic Codes
· This coding system involves the use of letters to identify items. The coding system may be mnemonic (e.g. H2O represents water) or alphabetic according to a set rule (e.g. NY represents New York).
· The main advantage of the approach is that it facilitates quick reference to items.
· One drawback is that if not controlled, the code used can be too long and confusing.
6. Self-checking Code
· In this coding system, a check digit (or number) is mathematically calculated and applied to the code.
· This approach is particularly useful in situations where data validation is required after transmission over telecommunication channels.
· The approach is redundant in situations where electronic transmission is not required.
2.4.2 Forms Design
A significant proportion of data input to a business information system will be done with the use of forms. For instance, most universities and colleges require applicants to fill out application forms. Completed application forms are then used to key data into some database for subsequent processing. When an applicant is accepted, it is this same data from the application form that is used as the student’s personal information.
Forms design provides the following advantages:
· Elimination redundant operations
· Reduction of the organization’s operational cost
· Facilitation of filing and retrieval
· Enabling of easy data capture
· Facilitation of interdepartmental flow
· Facilitation of control e.g. assigning a form number or color code
A form has three parts: a heading, a body, and a footing. The heading should contain the important company information (for example the company name), along with a descriptive title for the form. The body contains the essential details that the form contains. The footing contains instructional guidelines, and is optional (some forms are self-explanatory and therefore do not need footnotes). Figure 2-2 indicates the three styles for providing/requesting information on a form – open style, box style, or a mixture of both.
Figure 2-2. Form Fill-in Styles Used
There are three broad categories of forms, as described below:
1. Cut Sheet Forms: These are usually made in pads; sheets can be detached. This is the most common type of form.
2. Specialty Forms: There are four basic types of specialty forms:
· Bound in books e.g. receipts
· Detachable stub e.g. check
· Mailer
· Continuous e.g. machine printed report
3. Electronic Forms: These are forms for which there may or may not be printed versions. They serve as either data collection instruments for system input, or information dissemination instruments for system output.
Guiding Principles of Forms Design
In designing forms, the following guiding principles are important:
· Captions must be unambiguous; instructions must be clear, copies must be numbered or color-coded and/or numbered.
· The form should require minimum writing by the person filling it in, collecting only necessary data.
· Arrangement of information must be logical and subservient to efficiency.
· The form must be easy to fill out.
· The completed form should be easy to use in the system.
· The form layout must be consistent with input screen design (see chapter 11).
· The form must have good legibility features. In support of legibility, the Le Courier's legibility chart is famous (Figure 2-3).
Figure 2-3. Le Courier’s Legibility Chart
2.4.3 Data Analysis Charts
Data analysis charts are used to present information in a clear, concise manner. Uses of charts include:
· Analysis of trends
· Forecasting of future events
· Comparison of data
· Conveying technical information about the requirements of a system
Four commonly used types of charts (illustrated in Figure 2-4) are:
· Line Chart, as used in regression analysis and break-even analysis
· Pie Chart, used to show percentage distributions
· Bar Chart, used to show movements and relationships
· Step Chart, as in a histogram
Figure 2-4. Examples of Various Charts
2.4.4 Technical Documents and Modeling Techniques
In carrying the responsibilities of the job, the software engineer prepares several technical documents. There are no set rules or formats for these; the software engineer may be as innovative as he/she wishes provided that the following guidelines are observed:
· The document must be concise, but comprehensive in its treatment of the related subject.
· Where relevant, established tools and techniques must be employed.
The following are some examples of technical documents (typically referred to as deliverables) that the software engineer might be responsible for preparing:
· Project Proposal
· Initial System Requirement
· Feasibility Report
· Requirements Specification
· Design Specification
· Help System
· User’s Guide
· System Manuals
With respect to modeling techniques, this course, along with a course in OOM, will cover most of the established techniques that are at the disposal of the software engineer. Additionally, the experienced software engineer will from time to time, devise innovative variations of standard techniques, commensurate with the problem domain under consideration. He/she may even propose new techniques. To think about it for a moment, all the methodologies and techniques that are covered in this course are approaches that were developed by software engineers, in their attempts to solve problems.
2.4.5 Software Planning and Development Tools
Software planning and development tools were mentioned in the previous chapter. They may be loosely classified as modeling and design tools, database planning tools, software development tools, and DBMS suites. Some of the popular products have been included in Figure 2-5 (in alphabetic order). Please note that this is by no means a comprehensive list. As you view it, please note the following:
· Software engineering is a challenging, exciting, and rewarding field that is supported by a rich reservoir of excellent resources to help you learn and gain mastery in the discipline.
· Terms such as CASE tool and RAD tool describe a wide range of software systems that include any combination of the above-mentioned classifications (for more on this, see appendix 7). One’s choice of CASE/RAD tool(s) will depend on the prevailing circumstances and the desired objectives for the software engineering project.
Figure 2-5. Some Popular Software Planning and Development Tools
Given such a wide plethora of software engineering tools and resources, the matter of software evaluation and selection becomes pertinent to the success of a software engineering venture. Evaluation and selection should be conducted based on clearly defined criteria. This process will be further discussed in the upcoming chapter.
You have no doubt noticed that many of the tools mentioned in figure 2-5 relate to the field of database systems. This happens to be a very important field of software engineering that will be summarized in chapter 10, but which you will (or should) study in a separate course. A database management system (DBMS) is the software that is used to develop and manage a database. There are two main categories of DBMS suites (see [Date, 2004] and [Foster, 2010]):
· Relational: A relational DBMS supports the relational model for database design.
· Universal: A universal DBMS supports the relational model as well as the object-oriented model for database design.
CASE tools may be placed into three broad categories, each with three sub-categories [Martin, 1993]:
· Traditional: A traditional CASE tool is CASE tool that is based on the (traditional) function-oriented approach to software development. It may be a front-end system (concentrated on software investigation, analysis and specification), a back-end system (concentrated on software development), or an integrated (concentrated on the entire SDLC).
· Object-oriented: An OO-CASE tool is a CASE tool that is based on the OO paradigm for software construction. It may be front-ended, back-ended, or integrated.
· Hybrid: A hybrid CASE tool is a CASE tool that supports both the FO paradigm and the OO paradigm for software construction. It may be front-ended, back-ended, or integrated.
Most RAD tools tend to be object-oriented. Moreover, the distinction between CASE and RAD is not always well defined. However, what is not in question is spectrum of significant benefits that these software development tools bring to the software engineering discipline. These benefits include (but are not necessarily confined to):
· Automated project management techniques (see chapter 8)
· System modeling (including database and user interface)
· Conveniences of graphical user interface
· Prototype modeling and testing
· Sophisticated diagramming techniques, including executable diagrams
· Fourth generation language (4GL) interface to aid in application development
· Automatic code generation
2.5 Management Issues with Which the Software Engineer must be Familiar
Whether your organization is a software engineering firm, or a typical business that specializes in some (traditional or non-traditional) field of interest, there is a virtual inevitability that it will need the services of software engineers. Once the enterprise relies on, uses, or markets software, such services will be required. Software engineering has therefore become a pervasive, ubiquitous discipline.
The software engineer must be acquainted with plans that will significantly affect the organization. The effects may be in any of a number of areas, for instance:
· Plans for expansion, or contraction, or reorganization might affect the physical infrastructure of the organization.
· Relocation will affect the physical infrastructure also.
· A merger or contraction will affect the scope of the organization’s information infrastructure.
· Changes in the methods of internal work (e.g. budget preparation) or mode of operation (global or in specific areas), might require adjustment to underlying information system operations.
· Changes in the business focus of the enterprise may also impact on organization’s information infrastructure.
In many cases, these changes directly impact the software systems on which the organization relies; in other instances, the effect is indirect. Whether the effects are direct or indirect, the underlying systems may require modification, and the software engineering team will be required to implement these modifications.
2.6 Summary and Concluding Remarks
Here is a summary of what we have covered in this chapter:
· The software engineer is responsible for the investigation, analysis, design, construction, implementation and management of software systems in the organization. This requires a highly skilled individual with certain desirable qualities.
· The software engineer uses a number of important tools in carrying out the functions of the job. These include coding systems, forms design, charts, diagrams, technical documents, and software development tools.
· Coding systems allow for data representation, particularly during database design and forms design.
· Forms design relates to data collection instruments for input to as well as output from the system.
· Data analysis charts are used for data representation in a concise, unambiguous manner. Line charts, pie charts, bar charts and step charts are commonly used.
· Technical documents convey useful information about the work of the software engineer. These include but are not confined to project proposal, initial system requirement, feasibility report, requirements specification, design specification, help specification, user’s guide, and system manual. We will discuss these documents as we proceed through the course.
· Flow charts and other diagrams will be discussed later in the course.
· Software planning and development tools are available in the form CASE/RAD tools and SDKs in categories such as model and design tools, database planning tools, software development tools, and DBMS suites.
· The software engineer must be aware of any planned organizational changes that will have direct or indirect implications for the software systems of the organization.
This completes the introductory comments about software engineering. 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 few chapters will discuss various issues relating to software requirements investigation and analysis.
2.7 Review Questions
1. Prepare a job description for a software engineer in a software engineering firm.
2. Propose coding systems for the following:
· Animals in a zoo
· Employees in an organization
· Students at a college
· Resources in a college library
· Airline flights at an international airport
3. Imagine that you were employed as a software engineer for a firm. Your team is in the process of overhauling the company’s information infrastructure. You have been asked to propose a front-end software application that will automate the job application process. Do the following:
· Propose a job application form for the company.
· Identify the steps that you envisage that a job application would pass through.
· After an applicant has been employed, what (internal) software system(s) do you suppose your application processing system would feed its output into? Why?
4. Give examples of technical documents that software engineers have to prepare in the course of their job.
5. Give examples of some contemporary software planning and development tools that are available in the marketplace.
6. Why do software engineers need to concern themselves with management issues in an organization?
2.8 References and/or Recommended Readings
[CDP, 2006] CDP Print Management. Le Couriers Table of Legibility. 2006. http://www.cdp.co.uk/lecourierstable.shtml (accessed July 2009).
[Date, 2004] Date, Christopher J. An Introduction to Database Systems 8th ed. Reading, MA: Addison-Wesley, 2004.
[Foster, 2010] Foster, Elvis C. with Shripad Godbole. Database Systems: A Pragmatic Approach. Bloomington, IN: Xlibris Publishing, 2010.
[Martin, 1993] Martin, James. Principles of Object Oriented Analysis and Design. Eaglewood Cliffs, NJ: Prentice Hall, 1993.
[Pfleeger, 2006] Pfleeger, Shari Lawrence. Software Engineering Theory and Practice 3rd ed. Upper Saddle River, NJ: Prentice Hall, 2006. See chapter 2.
[Schach, 2005] Schach, Stephen R. Object-Oriented and Classical Software Engineering 6th ed. Boston, MA: McGraw-Hill, 2005. See chapter 5.