In 1975, Frederick P. Brooks [1] stated that ‘adding manpower to a late project makes it later.’ For centuries this law has been considered as one of the most cardinal principle of software project management. This article examines whether Brooks’s Law still holds true and tries to analyze the reasons of it and the relevance of Borrks’s Law in today’s software development environment.

CONTENTS

Introduction
Today’s Software Development Scenario
Project Cost
Written Communication
References

INTRODUCTION

In 1975, Frederick P. Brooks [1] stated that ‘adding manpower to a late project makes it later.’ For centuries this has been considered as one of the most cardinal principle of software project management. In 1995 Brooks [2] wrote the following in the 20th Anniversary Edition of his original book “…There have even been studies evaluating the truth of Brooks’ (intentionally simplistic) Law, that adding manpower to a late software project makes it later.

The best treatment is that of Abdel-Hamid and Madnick…” Hamid and Madnick [3] say that adding more people to a late project always make it more costly, but it does not always cause it be completed later. Brooks have taken into account the additional time taken to train the new people, the work lost due to repartitioning the work among increased project size, the time lost due to the increased complexity of communication, when new people are added to a late project and have stated his law that this addition will only make it later.

All the factors that Brooks considered are there in every project. But in today’s software development environment we cannot ensure that all the members of a project team will remain unchanged from the start to the end of the project as the project have become more complex and large and the size and complexity are increasing. So, today the relevance of Brooks’ law is somewhat limited.

TODAY’S SOFTWARE DEVELOPMENT SCENARIO

With the advent of modern software development tools (like CASE, integrated development environments, program generators, etc.) the training time is limited to learning the functionality of the project. This is because the employees of an organization will be trained in the software development tools and techniques that are being used in the organization.

Management can make sure that the people who are introduced to the project are people who have the necessary training on the tools and are familiar with the organizations standards and practices. So the training required is limited to understanding the functionality of project. In large projects, not all the team members have the full understanding of the system and that is not needed either. All they require is an overview of the system and detailed understanding of their subsystem or module. Imparting this training can be done outside the project and for this one does not have to interrupt the people who are working on the project. Also when the new people are familiar with the standards, conventions and procedures of the organization, the time lost in communication is also greatly reduced.

Another aspect is that, the new people can do the learning on their own; they can make use of the CBTs, project documentation and so on to make them knowledgeable and current in the work allotted to them. So in most cases, if good people (people who are bright, who are familiar with the organization and its working environment, the tools used and who can learn thing quickly) are chosen, then the time its takes for such a person to reach full productivity is negligible compared to the additional work that can be completed by him.

Here the important thing is the organizational culture, practices and policies. All the employees should be familiar with the working practices and standards of the organization, the tools used for software development, and so on so that they are interchangeable. The higher the degree of interchangeability of the employees the less is the difficulty for the management to add new people to a project and still not suffer from time overruns.

PROJECT COST

Another aspect of this scenario is the cost—whether adding manpower to a project will increase the project cost? If we consider the budget or the initial estimate, yes it will increase. But that is only part of the picture. We have to look at the project cost from the organization’s viewpoint. There are indirect costs like the overhead costs, opportunity costs, penalties and other intangible aspects like customer goodwill, company’s reputation and so on.

Today, most of the project contracts have penalty clauses; i.e., if the project is not completed within the specified date, the company has to pay the client penalty for the delay. In one project that the authors have worked, the project was for an international securities clearing agency. The deadline for the project was the 3^rdof October. This is because that was the only time during the year that the company had 3 days holiday. So if the project didn’t go live on the 3^rdof October, then the only chance to make the system changeover was in the next year. So the contract had a penalty clause—our company will have to pay a sum of $10,000 each day for the next one year, if it missed the October 3^rd deadline. Consider a situation where the company misses the deadline. The penalty that the company will have to pay the client is an astounding $3,650,000! This itself was a good motivating factor for us to complete the project on schedule and it is no wonder that we completed the project one month ahead of schedule. Not all projects will have such penalty clauses, but there will be penalty for the number of days delayed or something similar.

Consider another scenario where a company has planned to launch a product on a particular date. If the project is not complete by that date, the company is missing a market opportunity, may be an opportunity to be the first in the market. Also, if the product launch is announced, people have booked for the product and if the product is not available on the promised date, the company’s reputation is at stake. Not all companies can do what Microsoft does and still mange to get away with it! So a delayed project will result in negative press reports, loss of customer good will and tainted company reputation and it will also give the competition an opportunity to grab more market share.

CONCLUSION

So, if we consider all these factors, adding manpower, people who are right for the task (as we have described earlier), need not make a project late. In fact in most of the projects the authors have worked and managed, we were able to meet the deadline or finish ahead of schedule by adding more people. Here the only thing that one should consider is that, just adding new, untrained employees to a project will create the same effect that Brooks had predicted. But if you choose the people who are right for the job, and infuse them into the project and if the organizational environment is conducive for interchangeability, then the project will not be late.

Now regarding cost, yes additional manpower means additional expenditure. But when we consider the total costs (from an organizational viewpoint), the delayed completion will turn out to be more expensive in the case of tangible and intangible costs.

REFERENCES

[1] Brooks, F.P., The Mythical Man Month, Reading, MA: Addison Wesley Publishing Company, Inc., 1975.
[2] Brooks, F.P., The Mythical Man Month: Essays on Software Engineering (Anniversary Edition), Reading, MA: Addison-Wesley, 1995.
[3] Abdel-Hamid, T. and Madnick, S., Software Project Dynamics: An Integrated Approach, Englewood Cliffs, NJ: Prentice Hall, 1991.

Copyright © Alexis Leon. Reproduced with permission.

This article gives the syllabus of the Anna University course in Database Management Systems (CS 1301) and explains how the book Fundamentals of Database Management Systems could be used efficiently, effectively and quickly to learn the subject fulfilling the aim and objectives of the course.

CONTENTS

Aim
Objectives
Syllbus

Unit I – Introduction and Conceptual Modeling
Unit II – Relational Model
Unit III – Data Storage And Query Processing
Unit IV – Transaction Management
Unit V – Current Trends

Summary

AIM

This main aim of this course is to provide a strong foundation in database technology, database management systems and to provide an introduction to the current trends in database field.

OBJECTIVES

The main objectives of this course are:

• To learn the fundamentals of data models and to conceptualize and depict a database system using E-R diagram.
• To make a study of SQL and relational database design.
• To understand the internal storage structures using different file and indexing techniques which will help in physical database design.
• To know the fundamental concepts of transaction processing—concurrency control techniques and recovery procedures.
• To have an introductory knowledge about the emerging trends in the area of distributed DB- OO DB- Data mining and Data Warehousing and XML.

Unit I – Introduction and Conceptual Modeling

01. Introduction to file and database systems [Chapter 1]
02. Database system structure [Chapter 1]
03. Data Models [Chapter 03]

Hierarchical model [3.4]
Network model [3.5]
Relational Model [3.6]
E-R model [3.7]

04. Relational Algebra [Chapter 10]
05. Relational Calculus [Chapter 11]

Unit II – Relational Model

01. Introduction to SQL [Chapter 12]
02. Data definition [Chapter 15]
03. Queries in SQL [Chapter 16]
04. Updates [Chapter 18]
05. Views [Chapter 15]
06. Integrity and Security [Chapters 7, 27 and 28]
07. Relational Database design [Chapters 2, 7, 8 and 9]
08. Functional dependences [Chapter 9]
09. Normalization for Relational Databases (up to BCNF) [Chapter 9]

Unit III – Data Storage and Query Processing

01. Secondary storage devices [Chapter 23]
02. Record storage and primary file organization [Chapter 24]
03. Operations on Files [Chapter 24]

Heap File [Forthcoming Article]
Sorted Files [Forthcoming Article]

04. Indexing and Hashing [Chapter 25]

Hashing Techniques [25.3]
Index structure for files [25.2]
Different types of Indexes: B-Tree, B⁺-Tree [25.2.1.3 and 25.2.1.4]

05. Query Processing [Chapter 26]

Unit IV – Transaction Management

01. Transaction Processing [Chapter 29]

Need for concurrency control [29.6]
Desirable properties of transaction [29.3]
Schedule and Recoverability [29.8]
Serializability and Schedules [29.7]
Concurrency Control [29.9]
Types of Locks [29.9.1]
Two-phase locking [29.9.2]
Deadlock [29.9.3]
Timestamp-based concurrency control [29.9.5]

02. Recovery [Chapter 30]

Recovery Concepts [30.11, 30.12 and 30.13]
Recovery Techniques [30.15]
Deferred Update [30.15.1]
Immediate Update [30.15.2]
Shadow Paging [30.15.3]

Unit V – Current Trends

01. Object Oriented Databases [Chapter 33]

Need for complex data types [33.1 and 33.2]
Object-oriented data model [33.3 and 33.4]
Nested relations, Complex Types, Inheritance, Reference Types [33.5]

02. Distributed databases [Chapter 32]

Homogenous and heterogeneous distributed databases [32.7]
Distributed data storage [32.8]

03. XML [Chapter 34]

XML Data [34.10 and 34.11]
XML Document [34.1 and 34.5]
XML Schema [34.1 and 34.5]
Structure of XML [34.6]
Querying and Transformation [34.15]

04. Data Warehousing [Chapter 36]
05. Data Mining [Chapter 37]

01. Concepts in Enterprise Resource Planning

• Author(s): Ellen Monk, Bret Wagner
• Publisher: Course Technology
• Edition & Year: Second, 2005
• ISBN: 0619216638
• Binding & Page Count: Paperback, 248 pages

02. ERP: Making It Happen

• Author(s): Thomas F. Wallace, Michael H. Kremzar
• Publisher: Wiley
• Edition & Year: 2001
• ISBN: 0471392014
• Binding & Page Count: Hardcover, 384

03. ERP Systems: Systems, Life Cycle, E-commerce, and Risk

• Author(s): Daniel E. O’Leary
• Publisher: Cambridge University Press
• Edition & Year: First, 2000
• ISBN: 0521791529
• Binding & Page Count: Hardcover, 232

04. Enterprise Resource Planning

• Author(s): Mary Sumner
• Publisher: Prentice Hall
• Edition & Year: First, 2004
• ISBN: 0131403435
• Binding & Page Count: Paperback, 208

05. ERP: The Implementation Cycle

• Author(s): Stephen Harwood
• Publisher: Butterworth-Heinemann
• Edition & Year: First, 2003
• ISBN: 0750652071
• Binding & Page Count: Paperback, 183

06. E-Business and ERP: Rapid Implementation and Project Planning

• Author(s): Murrell G. Shields
• Publisher: Wiley
• Edition & Year: First, 2001
• ISBN: 0471406775
• Binding & Page Count: Hardcover, 208

07. ERP: A-Z Implementer’s Guide for Success

• Author(s): Travis Anderegg
• Publisher: Resource Publishing
• Edition & Year: First, 2000
• ISBN: 0970035217
• Binding & Page Count: Paperback, 750 pages

08. Mission Critical: Realizing the Promise of Enterprise Systems

• Author(s): Thomas H. Davenport
• Publisher: Harvard Business School Press
• Edition & Year: First, 2000
• ISBN: 0875849067
• Binding & Page Count: Hardcover, 352 pages

09. E-Business and ERP: Transforming the Enterprise

• Author(s): Grant Norris, James R. Hurley, et. al.
• Publisher: Wiley
• Edition & Year: First, 2000
• ISBN: 0471392081
• Binding & Page Count: Hardcover, 216 pages

10. Managerial Issues of Enterprise Resource Planning Systems

• Author(s): David Olson
• Publisher: McGraw-Hill/Irwin
• Edition & Year: First, 2003
• ISBN: 0072861126
• Binding & Page Count: Paperback, 192 pages

11. ERP Optimization: Using Your Existing System to Support E-Business Initiatives

• Author(s): Cindy M. Jutras
• Publisher: CRC Press
• Edition & Year: First, 2002
• ISBN: 1574443321
• Binding & Page Count: Hardcover, 160 pages

12. ERP: Tools, Techniques, and Applications for Integrating the Supply Chain

• Author(s): Carol A. Ptak, Eli Schragenheim
• Publisher: CRC Press
• Edition & Year: Second, 2003
• ISBN: 1574443585
• Binding & Page Count: Hardcover, 464 pages

13. Integrated Learning for ERP Success: A Learning Requirements Planning Approach

• Author(s): Karl M. Kapp, William F. Latham and Hester N. Ford-Latham
• Publisher: St. Lucie Press
• Edition & Year: First, 2001
• ISBN: 1574442961
• Binding & Page Count: Hardcover, 368 pages

We will see the different steps of the requirements analysis in this article. Requirements analysis is one of the most important phases of the DDLC as the users’ requirements are captured during this phase. If this phase is not done properly, we will end up designing a system that the user does not want or something that does not satisfy the user’s business needs.

CONTENTS

Introduction
Business Objects
Business Rules
Users of Data
Requirements Analysis Documentation
Data Flow Diagram
User Views
Summary

INTRODUCTION

The first step in implementing a database system is to find out what is required. What kind of a database is needed for the organization, what is the volume of the data that must be handled on a day-to-day basis (transaction data), how much data is to be stored in the master files, and so on. This phase is called the Requirements Analysis.

Requirements analysis is the first and most important stage in the DDLC. It is also the most labor-intensive for the database designer. This stage involves assessing the informational needs of an organization so that a database can be designed to meet those needs. The overall purpose of requirements analysis is to gather every bit of information needed to design a database that meets the informational needs of an organization. This is accomplished by performing a series of related tasks:

• Examine the existing database(s)
• Conduct user interviews
• Create a data flow diagram (if needed)
• Determine user views
• Document all findings

It is critical for the designer to approach requirements analysis armed with a plan for each task in the process. Experience is the great teacher when it comes to assessing informational needs, but there is no substitute for preparation, especially for new designers. Most database designers begin requirements analysis by examining the existing database(s) to establish a framework for the remaining tasks. Analyzing how an organization stores data about its business objects, and scrutinizing its perception of how it uses stored data (for example, gaining familiarity with its business rules) provides that framework.

BUSINESS OBJECTS

Identifying an organization’s business objects is typically the first order of business during requirements analysis. Since most database design situations involve businesses that already have some sort of database in place, the first place to look for business objects is in the existing database, whether legacy, paper-based, or both.

Business objects are things (both tangible and intangible) in a business environment that are related, and about which data is (or needs to be) stored. Employees, projects, customers, appointments, products, orders, suppliers–all of these are objects about which organizations store information. During requirements analysis, business objects must be identified and sorted according to subject. If two or more distinct subject categories appear, a database should be created for each. Keep in mind that every organization makes decisions about which business objects it will and will not store data about. For example, for a small business, the owners might decide they do not want to have any data about themselves (as owners/employees) stored on the company database. Business objects are converted into entities in the logical design stage. Entities, in turn, are ultimately translated into database tables with SQL. Every business object has characteristics that describe it. Customers, employees and suppliers, for example, will have names, addresses, phone numbers, and so on. Products will have names, prices, descriptions, and so on. Appointments will have times, dates, and so on. In fact, if you cannot identify two or more characteristics of a business object, there’s a strong possibility it’s not a business object at all. Figure 1 gives a list of sample business objects and their characteristics, appropriate to a wide range of databases.

Figure 1 SDLC phases and their relationship with DDLC

The characteristics of business objects are converted into the attributes of entities in the logical design stage. Attributes, in turn, are ultimately translated into table fields with SQL. Business objects relate to each other in some form or fashion. Customers place orders, employees take orders, orders are for products, products come from suppliers, and so on. Relationships between objects can be complex, so establishing relationships at this point in the design process is quite preliminary. It is important to note, however, what objects are generally related, especially in the existing database(s). As part of requirements analysis, database designers list and document the business objects stored in the client’s existing database(s), along with their characteristics and a preliminary idea of how they are related.

BUSINESS RULES

Business rules describe the business policies that apply to the data stored on a company’s databases. In other words, business rules reflect how a business perceives its use of data. Some business rules are especially important to the database designer because they can be incorporated into the logical schema of the database. There are certain constraints that designers apply to ensure that a database honors a company’s business rules. These constraints help preserve data integrity. Business-rule constraints fall into two categories—field constraints within tables, and relationship constraints between tables. There are various field constraints that can be imposed on a database to honor business rules. Consider the example below:

• Business rule: We ship our products to customers in four states only: Kerala, Tamilnadu, Karnataka and Andhra Pradesh.
• Field constraint: These states are represented in a Customers table in a field called State as: Kerala, Tamilnadu, Karnataka and Andhra Pradesh. A constraint is placed on the State field so that only those four states are accepted into the database for that specific table.

Constraints are especially common on date fields, where dates would become meaningless in a database if a product’s ship date, for example, was earlier than the customer-order date for that product, or if an employee’s termination date was prior to his/her hire date! There are also various constraints that can be placed on the relationships (links) between tables. Consider the example below:

• Business rule: Every vendor must supply at least one product.
• Relationship constraint: The relationship between the Vendors table and Products table must be governed by a participation constraint wherein a single record in the Vendors table must be related to at least one record in the Products table.

Additionally, relationship constraints dictate that certain tables in a relationship have mandatory status, while others have optional status. Documentation continues for the designer, who should be creating a list of business rules for the organization as reflected in any constraints (if applicable) placed on the existing database(s). Developing an eye for constraints is mostly a matter of experience.

USERS OF DATA

Having completed your analysis of the existing business objects and rules, the next logical step in the process of Requirements Analysis is to interview those within the organization who use the data in the database. Their collective insights into how data is used helps in revising (for example, adding to or subtracting from) the list of business objects and rules collected earlier. Users of data include an organization’s employees and managers. There are three major reasons why users of data are interviewed by database designers:

• To determine how data are currently being used and perceived
• To determine whether users require additional information
• To determine future growth requirements

How an organization currently uses its data is determined not only by examining the existing database(s), but also by interviewing those who use the data. Pegasus Books, for example, has a data-entry form to process customer orders and a listing of its distributors in a Rolodex. Current informational needs of the company prescribe that distributors be considered a business object.

Interviewing the current users of data—the owners of the store, in this case—has uncovered this “out of sight” paper-based data sources. Rarely will an analysis of an organization’s existing database–whether legacy or paper-based–reveal the full range of an organization’s informational needs. If that were the case, the role of the database designer in creating a database would be greatly diminished. Interviewing data users about future needs enables the designer to rethink design options. For example, if the interview of owners revealed that they intended to sell Books outside India in about 18 months, the designer might refrain from placing any field constraints on address-related fields that would preclude data entry about overseas customers. Again, documentation of the interviews is extremely important. As questions arise while designing the logical schema, notes taken here are reviewed and can point the designer in the right direction if more user information is needed.

REQUIREMENTS ANALYSIS AND DOCUMENTATION

All the tasks performed during Requirements Analysis should be carefully documented, as these documents carry over into the remaining DDLC design stages. After completing Requirements Analysis, the following documents should be in hand:

• A preliminary list of business objects (sorted by subject), their characteristics, and how they relate to one another
• A specification sheet for business rules (including possible constraints)
• An assessment of future informational needs
• A specifications sheet for user views (including needed calculations)
• A data flow diagram (if it was determined one was needed)

Several of these documents will be immediately useful for creating the database’s logical schema. The data flow diagram may come in handy later on for creating database applications and revising user views. Documentation is also important should conflicts arise later about the quality of the database design. All interested parties should have access to clear and concise documentation about the entire process of needs analysis.

DATA FLOW DIAGRAM

As part of Requirements Analysis, the designer may request organizational charts from the business, and supplement these charts with information gathered during interviews with users to assess how data flow is handled within the organization. He or she uses this information to create a data flow diagram. These diagrams are useful to the designer in establishing user views across multiple databases (and also in determining if multiple databases are needed) and in sorting business objects by subject matter.

While there are different styles of data flow diagrams, they are quite similar in appearance and function and are read in the very same way. The two main styles of data flow diagrams are the Yourdon/DeMarco style and the Gane & Sarson style. The Yourdon/DeMarco uses squares, circles, and parallel lines to represent data handlers, processes, and databases, respectively. The Gane & Sarson style, on the other hand, uses squares, round-cornered rectangles, and open-ended rectangles to represent data handlers, processes, and databases, respectively. The Yourdon/DeMarco data flow diagram (see Figure 2), for example, includes symbols that illustrate:

• Who handles the data (text enclosed in a square)
• Where the data moves (arrows on the diagram)
• Where the data are stored (text surrounded by parallel lines)
• What is done to the data (text inside a circle)

Figure 2 Data Flow Diagram

Figure 2 illustrates a typical Yourdon/DeMarco data flow diagram. Given below is the explanation of the different steps shown in the figure:

1. An employee takes the customer order.
2. The order is stored in the database.
3. An employee prepares the order for shipment.
4. The order is shipped to the customer.
5. The ship date is recorded in the database.

Also note the use of the symbols in the diagram:

• Text surrounded by a square indicates people who handle the data.
• Arrows connecting text indicate the movement of data.
• Text within circles indicates an operation performed on the data.
• Text enclosed by parallel lines indicates where the data is stored.

It is not always necessary to create a data flow diagram. For example, Pegasus Books is small, with only one subject database. It is not necessary to create a diagram to understand the flow of data in this instance. Views created for this company would provide specific information in a specific format, and those views could be documented without recourse to a data flow diagram. However, a large organization with several subject databases (or one very large database) will require numerous user views that draw from different databases. In this case, a data flow diagram is important for two reasons:

• To determine what data from which databases go into different user views
• To assist application designers in planning database application programs

The larger the organization for which you’re designing database(s), the more important it is to create a data flow diagram.

USER VIEWS

The data flow diagram, combined with specific questions posed to users of data about their needs, paves the way for the designer to create user views. User views are specific views of data created with SQL. The designer defines what data (from what database tables) are made available in these stored queries. There are three important reasons for creating user views:

• Data security – User views were defined earlier in terms of data security. They specify which users are permitted access to what data in a database (or across databases). User views ensure that sensitive data remains hidden from unauthorized eyes.
• Specific user needs – Creating views to meet specific user needs is the flipside of the data security issue. Users must have access to certain data to perform their jobs. It is counterproductive for users to have to wade through data that is irrelevant to their work.
• Calculated fields – The tables actually stored in a database (called base tables) should not have any type of calculations built into their fields. The reason for this is simple: every field in a base table uniquely and independently stores data about the subject of its table. If calculation were permitted in base tables, then the data stored in some fields would depend for their values on data stored in other fields. User views, however, store their data in virtual tables that consist of fields loaded into computer memory from base tables. Virtual tables themselves are not stored in the database; rather, the definition of the view is stored and given a name. Users call up that name, and the view is created (from base tables) on the fly. When a user closes the view, it “disappears” from memory, only to be recreated the next time its name is invoked. A user view (like a database application) allows calculations to be performed on the data contained in its fields. That’s because these field calculations within virtual tables have no effect on the data stored in the base tables. One significant reason to create user views, then, is because, through calculations, views can deliver extremely useful information.

User views, therefore, not only protect sensitive data within an organization; they also protect users from being inundated with useless data.

SUMMARY

We have seen the different steps of the requirements analysis. Requirements analysis is one of the most important phases of the DDLC as the users’ requirements are captured during this phase. If this phase is not done properly, we will end up designing a system that the user does not want or something that does not satisfy the user’s business needs.

RELATED ARTICLES:

01. Database Development Life Cycle (DDLC)

In this article, we will see the different phases of the software development life cycle and the database development life cycle. Database development lifecycle (DDLC) is a subset of the SDLC or we can say that the DDLC is part of the SDLC. The different phases of DDLC are requirements analysis, database design, DBMS evaluation, selection, implementation, data loading, testing, operation, performance tuning, and maintenance. We will also see the different activities performed in each phase and the output generated in each phase.

CONTENTS

Introduction
DDLC Phases

Requirements Analysis
Database Design
Evaluation and Selection
Logical Database Design
Physical Database Design
Implementation
Data Loading
Testing and Performance Tuning
Operation
Maintenance

Summary

INTRODUCTION

The software development is that set of actions required for efficiently transforming the user’s need into an effective software solution. Software development process defines the activities required for building the software systems, incorporating the methods and practices to be adopted. It also includes the activities essential for planning the project, tracking its progress and managing the complexities of building the software.

The life span of software systems varies from product to product. During its lifetime, the software goes through various phases. IEEE defines software lifecycle as the period of time that starts when a software product is conceived and ends when the product is no longer available for use. The software development lifecycle (SDLC) typically includes a requirements phase, design phase, implementation phase, testing phase, operation and maintenance phase, and sometimes, retirement phase. The database development life cycle (DDLC)is a part of (or embedded inside) the software development life cycle.Figure 1 gives the various SDLC phases and their relationship with DDLC.

Figure 1 SDLC phases and their relationship with DDLC

DDLC PHASES

In this section we will consolidate these different database related activities and group them into phases that form part of the database development life cycle (DDLC). The different phases of DDLC are:

• Requirements Analysis
• Database Design
• Evaluation and Selection
• Logical Database Design
• Physical Database Design
• Implementation
• Data Loading
• Testing and Performance Tuning
• Operation
• Maintenance

We will now see each of these steps in some detail and find out what exactly is done in each of these phases.

Requirements Analysis

The first step in implementing a database system is to find out what is required. What kind of a database is needed for the organization, what is the volume of the data that must be handled on a day-to-day basis (transaction data), how much data is to be stored in the master files, and so on. To get these information the database analysts should spend a lot of time in the organization talking to people—the end users—assessing their day-to-day tasks and analyzing the data needs and the amount of data they process and produce. In order to get an accurate estimate of the data needs, the volume of data that is to be handled by the proposed system, the database analysts need to spend time studying the system. Besides the data volume, the analysts should also gather detailed and accurate information on the number of users, the number of people simultaneously accessing the system, the performance expectations of the users, the rate at which the database will grow and so on. The main goals of this phase of DDLC are:

• Study the existing system – Here the objective is to identify the data needs and requirements, the data volume, the performance requirements, the security issues, data access restrictions, number and types of users, the growth rate of the database and so on.
• Define problems and constraints of the database environment – Here the objective is to find out the problems that will have to be solved when the database is designed. What are the areas where the designers have to be careful, in order to avoid producing a bad database design. Here the analysts should study the paper forms that are being used in the organization and then decide which data items are needed and which are redundant. This is a challenging job as it involves converting the grievances and complaints and expectations of the end users (who will not be familiar with the intricacies of database design) into meaningful requirement definitions. Here the analysts should sit with the users, question the need and necessity of each data item, the problems that can arise if a particular data item is missing, and so on and then arrive at the problem areas, constraints and limitations of the database system.
• Define the design objectives – The proposed database system should help in solving the information requirements of the organization and facilitate the smooth and efficient flow of information and help in better decision-making. Most organizations that plan to have a database usually have islands of information—each department having its own database. These islands should be removed and the information should be centralized. In order to do this the analysts should gather the information stored in the departmental databases and then integrate all of them to create an enterprise-wide information system. To do this—to create a centralized database that contains the information for the entire organization—the designers should have the overall view of the organizational goals and the organization’s structure. They should also address issues like data integrity, security, concurrency, performance and so on.
• Define standards and guidelines – The database design standards, the naming conventions, the documentation standards, diagramming standards and other conventions that are to be followed in the DDLC phases are also formulated during this phase.

Detailed discussion on the various steps involved in Requirements Analysis.

Database Design

In this phase the database designers will decide on the database model that is ideally suited for the organization’s needs. The database designers will study the documents prepared by the analysts in the requirements analysis phase and then will go about developing a system that satisfies the requirements. In this phase the designers will try to find answers to the following questions:

• What are the problems in the existing system and how they could be overcome?
• What are the information needs of the different users of the system and how could the conflicting requirements be balanced?
• What data items are required for an efficient decision-making system?
• What are the performance requirements for the system?
• How should the data be structured?
• How will each user access the data?
• How is the data entered into the database or how is the data loaded to the database?
• How much data will be added to the database each day/week/year?

First a conceptual design of the database is created. In the conceptual design stage, data modeling is used to create an abstract database structure that represents the real-world scenario. The conceptual model will be a true representation of the real world, only if the requirements analysis is properly done, as it needs a thorough understanding of the business and functional areas. At this stage the hardware or the database model that is to be used are not decided—the conceptual design is hardware and software independent. This is important as the system can be implemented on any software/hardware platform chosen later. The different steps in the conceptual design are as follows:

• Data Analysis and Requirements Definition – In this step the data items and their characteristics are determined. The data items that are required for successful information processing and decision-making are identified and their characteristics are recorded. Questions like what kind of information is needed, what outputs (reports and queries) should the system generate, who will use the information, how and for what purpose it will be used, what are the sources of the information, etc. will be answered in this step.
• Data Modeling and Normalization – In this step the database designer creates a data model of the system. The business contains entities and relationships. Each entity will have attributes. In this step the business entities and relationships are transformed into a data model (usually an E-R model) using E-R diagrams. Now many designers have started using data modeling using UML (Unified Modeling Language) instead of the E-R diagrams. Once the data model is created, then the data will be available in a structured form. All objects (entities, attributes, relations and so on) are defined in a data dictionary and the data is normalized. During the process the designer will group the data items, define the tables, identify the primary keys, define the relationships (one-to-one, one-to-many or many-to-many), create the data model, normalize the data model and so on. Once the data model is created, it is verified against the proposed system in order to ascertain that the proposed model is capable of supporting the real-world system. So the data model is tested to find out whether the model can perform the various database operations (data loading, access, querying, insertion, modification and so on) and whether the data model takes care of the issues of data security, integrity, concurrency and so on.

Evaluation and Selection

Once the data model is created, tested and verified, the next step is to evaluate the different database management systems and select the one that is ideally suited for the needs of the organization. Here the very important thing to be remembered is that the end-user’s representatives should be made part of the group that evaluates and selects the database system for the organization. The main factors that influence the selection of the DBMS are:

• Cost of the System – The cost includes the purchase price, cost of operation, maintenance, site license, installation, training, data migration, data conversion, etc.
• Features and Tools – Not all database management systems are created equal. Some systems have more features than others. Some have a lot of data administration, querying and report writing tools as part of the system. For example, the availability of Query-By-Example (QBE), screen painters, report generators, query generators, data loaders, data dictionaries and so on make the DBMS easy-to-use and pleasant to work with. Similarly DBA utilities, automated back-up/recovery systems, access control and management systems all make the DBMS more attractive to the buyer. But here a word of caution: you should not go out and buy the DBMS that has the most number of features and tools. You should buy the one that has the most number of features and tools that you want.
• Customer Support and Training – Another factor that will influence the selection of the DBMS is the efficiency of the customer service (after sales service) that the DBMS vendor offers. Also the ease of training, that is the ease with which users can be trained in the system is another factor.
• Underlying Data Model – The purchasing decision is to a very large extent influenced by the underlying data model—Hierarchical, Network, Relational, Object-Relational and so on.
• Portability – The DBMS selected should be portable across platforms and languages if there is a requirement for that.
• Hardware Requirements – The hardware requirements of the DBMS is another important factor. If the DBMS needs high-end systems to perform efficiently, then the cost of these hardware components should also be considered while making the selection.

Logical Database Design

Once the different database management systems are evaluated and the one best suited for the organization is selected, the next step in the DDLC is the logical database design. Logical design is dependent on the choice of the database model that is used. Once the database model is identified, the conceptual design can be mapped to the logical design that is tailored to the selected database model. So the logical design is software dependent.

In the logical design stage, the conceptual design is translated into internal model for the selected DBMS. This includes mapping all objects in the model to the specific constructs used by the selected database software. For example, for a RDBMS, the logical design includes the design of tables, indexes, views, transactions, access privileges, etc. Thus the logical design transforms the software-independent conceptual model into a software dependent model.

Physical Database Design

Physical database design is the process of selecting the data storage and data access characteristics of the database. The storage characteristics depends on the type of devices supported by the hardware, the type of data access methods supported by the system and the DBMS. Physical design translates the logical design into hardware dependent one. Physical design is particularly important for older database models like hierarchical and network models. Relational, object-relational, object-oriented and deductive models are much more insulated from the physical layer details than the older database models. But even in the case of modern database models, physical design has great significance as a bad design can result in poor performance. In the case of distributed databases the physical design becomes more complex as the networking and communications issues also come into the picture.

Implementation

In most databases a new database implementation requires the creation of special storage related constructs to house the end user tables. These constructs usually include storage group, tablespaces, data files, tables and so on.

Data Loading

After creating the database, the data must be loaded into the database. If the data to be loaded into the database is currently stored in a different system or in a different format, then the data needs to be converted and then migrated to the new database. Data conversion and migration tools and utilities are available with almost all database management systems in the marketplace. There are also a host of third-party tools to accomplish these tasks.

Testing and Performance Tuning

Once the data is loaded into the database the database is tested and fine-tuned for performance, integrity, concurrent access and security constraints. The testing and performance tuning occurs in parallel with the testing and performance tuning of the application programs. Sometimes, the performance degradation of the database is due to the inefficient code in the application program. So however hard the database administrator tries to fine-tune the database parameters, unless and otherwise, the application program logic is changed to a more efficient one, the performance will not improve. So it is important that the database administrators and application programmers work hand-in-hand during this phase.

Operation

Once the data is loaded to the database and it is tested, the database is released into production (along with the application programs). At this stage the database is considered to be operational and the database, its management, its users and the application programs together form an information system. During the operational phase, the database is accessed by the users and application programs, new data is added, the existing data is modified and some obsolete data is deleted. The database administrators perform the administrative tasks like performance tuning, storage space creation, access control, database back up and so on. It is during the operational phase that the database delivers its usefulness as a critical tool in management decision-making and help in the smooth and efficient functioning of the organization.

Maintenance

Once the database is released into production, it will not remain as it was designed, New business requirements, need for new information, acquisition of new data and similar factors will make it necessary to make modifications and enhancements to the existing design. So the database administrators will definitely receive requests for more storage space, changes in the database design, addition of tables, addition of new users, removal of users who have left the organization, changes in the access privileges of the users and so on. The main tasks in this phase are:

• Database backup and recovery
• Performance tuning
• Database design modifications
• Database access management
• Database audits (access audits, usage audits, security audits, etc.)
• Usage monitoring
• Hardware maintenance
• DBMS Software upgradation

SUMMARY

We have seen the different phases of the software development life cycle and the database development life cycle. Database development lifecycle (DDLC) is a subset of the SDLC or we can say that the DDLC is part of the SDLC. The different phases of DDLC are requirements analysis, database design, DBMS evaluation, selection, implementation, data loading, testing, operation, performance tuning, and maintenance. We saw the different activities performed in each phase and the output generated in each phase.

RELATED ARTICLES:

01. Requirements Analysis

In the late 1990s and in 2000 we saw the dotcom boom. In 2001 we saw the dotcom doom. This article looks at the reasons for the failures of the Internet startups and examines the various strategies to prevent such failures. In other words this article discusses the dotcom survival strategies. The article also takes a peak into what is in store for the dotcoms.

CONTENTS

Dotcom Boom
Dotcom Doom
Lack of Customer Focus
Customer Experience
Customer Experience Gap
Bridging Customer Experience Gap
Internet Economy
The Future

DOTCOM BOOM

In the late 1990s and in 2000 we saw the dotcom boom. We saw the emergence of thousands of new dotcom companies. We saw them spending astronomical amounts on marketing, advertisement and promotion. We saw them recruiting (most of the times poaching) personnel at fancy salaries and even fancier perks. We saw the media glorifying the entrepreneurs (the new age CEOs, they were called). We saw their pictures on the covers of myriad business magazines and their stories inside. We heard them predicting their success stories on television talk shows. We saw venture capitalists vying with one another to get their attention. We heard about the million dollar mergers and acquisitions. We saw many young entrepreneurs making more money than they could spend.

DOTCOM DOOM

In 2001 we saw the dotcom doom. All the hype, all the glitz, all the ads, all the money and most importantly most of the dotcoms were gone. Gone were the high paying jobs, the posh offices, the power lunches with venture capitalists and the media adulation. Many ventures went down, many got acquired and very few managed to survive. Established companies spent almost $40 billion last year to scoop up bankrupt dotcom companies, taking advantage of bargain prices left by the Internet shakeout to bolster their online assets. A total of $39.7 billion was spent in 2001 for 1,289 Internet companies after a brutal market downturn forced scores of Web start-ups into bankruptcy sales, said Webmergers.com, a San Francisco online marketplace for Internet companies.

How did this happen? Was it bad luck or was it change in government policies? Was it recession or was it some other environmental factor? In my opinion all these factors must have contributed to some extent; but most of the dotcoms failed because of bad business ideas, nonviable business plans, flawed business models, bad financial management, use of wrong technology, inadequate use of technology, overuse of technology and so on.

LACK OF CUSTOMER FOCUS

There was one more reason—lack of customer focus—the reason that led to the downfall of more than 80% of the dotcoms. Most dotcom entrepreneurs thought that once they put up a fancy web site, spend a lot of money on advertisement and promotions, hire a lot of people, pay them fancy salaries, they can make their venture a great success. They were wrong; dead wrong. What they failed to realize was that they needed customers to succeed. They forgot the fact that customers just won’t surf into their shops. They failed to realize the fact that, they need to device strategies and formulate plans to make people visit the shops, turn the visitors into buyers and convert the one-time buyers into loyal customers. On the Internet, where the next shop is just a ‘mouse-click’ away; the customer is really the KING.

Customers can provide the revenues needed to attain profitability. Customers can give the word-of-mouth marketing to drive traffic. Customers can give the feedback needed to continually improve the website. Customers are a dotcom’s most important asset. To survive dotcoms must turn to their most important asset—CUSTOMERS. In other words, serve the customer and the money and profits will follow. Serving the consumer is the only business model that has a 100% guarantee of success.

CUSTOMER EXPERIENCE

Where does a dotcom connect with its customers? The dotcom can connect with its customers during all activities of the online shopping and fulfillment. This includes everything from surfing the web site, to the shopping and buying process, to the fulfillment of products and even to the after sales service. The customer experience is the combination of everything the customer sees, clicks, reads or otherwise interacts with on the web site. The quality of your customers’ experience when they do business with you determines brand loyalty. And the quality of that experience is based on several factors, including a thoughtful Web design, streamlined business processes, great customer service and flawless execution. The customer experience is the key to dotcom survival.

One way to improving the customer experience is to shift the business strategy to focus on the customer—solving customers’ problems, recognizing the limitations of technology (both on the web site and the at the customer end) and achieving simplicity in all respects.

CUSTOMER EXPERIENCE GAP

As the Web has become increasingly popular and accessible, the number of people who are online have grown exponentially. In the early days of e-commerce, mainly computer experts used the web and the web sites contained only text and graphics. Today for a customer base of new users, the Web serves up a complicated soup of frames, Java, cookies, plug-ins, banners, flash movies, secure servers, streaming audio, streaming video and so on.

Clearly, there is a difference between what the Web gives its customers and what they actually want. Customers want simplicity, but the Web offers complexity. Customers want service, but the Web offers technology. Customers want to accomplish their goal, but the Web offers “features.” In each case the Web doesn’t offer the experience that the customer wants. This phenomenon is called the customer experience gap—the difference between what customers want and what they get. There is a widening customer experience gap online. To survive, dotcoms must bridge the customer experience gap.

BRIDGING CUSTOMER EXPERIENCE GAP

In order to bridge the customer experience gap the dotcoms should make it easy for customers to find and buy products they want from the site. This may sound obvious, but many top e-commerce sites still make it too difficult for customers to find and buy their products. Another way to improve the quality of the customer service is offering personalized service to the loyal customers. A satisfied customer is worth his/her weight in gold. In addition to the revenue from the customer’s purchases, a happy customer also brings free word-of-mouth exposure—bringing even more customers to the site. Satisfied customers bring loyal, buying customers who want to bring in more loyal, buying customers. Thus by taking care of the needs of a single customer you are starting a chain reaction that will increase site traffic, number of visitors, number of buyers and definitely the revenues. But this has a negative side too. A dissatisfied customer will not only abandon the site permanently but also generate negative publicity by telling about the experience to others. An e-business may lose the lifetime value of several customers by providing one bad experience. With plenty of competing sites to visit, customers have little incentive to return to a site that has failed to meet their needs. One must always be on the alert—reading customer mails, responding to customer queries, suggestions and grievances, taking corrective actions before problems escalate, getting feedback from customers, and constantly monitoring the quality of service and customer care. Ensuring customer satisfaction is an ongoing process and everyone in the organization should be involved in the endeavor.

The art of merchandising or merchandise planning has enjoyed decades of refinement in the traditional brick and mortar shops. Today, e-commerce retailers have just begun to figure out how to effectively merchandise online. One way to think about online merchandising is to compare it to what works best offline—the salesperson. A literal translation of the live salesperson to the Internet usually creates a bad customer experience. By not recognizing the technological constraints of the medium, sites that have tried to emulate the salesperson with “virtual sales assistants ”have mostly failed in their merchandising attempts.

A Forrester report (“The Promotion Commotion,” April 2000) found that targeting is the most important factor of success for online promotions. For perfect targeting, the retailer needs to have complete information on the specific shopper, including past purchase patterns, known needs, and even unarticulated desires. Obviously it is unreasonable for e-tailers to expect to capture that much information about their customers. But with a little common sense the online merchants can target their customers. They can study the purchasing patterns and offer similar products. They can organize occasion-based sales programs (for example, Christmas sales, Diwali sales, Valentine’s Day sales, etc.). The merchants can offer products suitable for each such occasion or season along with the regular products that the shop is offering. Special discounts, promotional offers, gifts, etc. can be used to attract more customers. The merchants can target the markets that make sense for their business and even can look for well-defined segments within that market. They must make sure that the marketing budget is being spent on attracting, retaining, and managing actual customers, and not just creating brand awareness. While advertising, spend well within the means. E-mail lists costs only a fraction of the cost of a contest or newspaper/magazine advertisement, but can be much more effective. Merchants can generate more revenue by a focused e-mail campaign than by placing a newspaper advertisement.

Another important aspect where most merchants fail is in effectively communicating with the customers. In the brick and mortar variety, face-to-face communication is possible. But in the online form, most of the communication is through e-mail. From order confirmations to responding to customer queries and complaints, e-mail is an increasingly important aspect of the customer experience. By giving timely order confirmations, order status reports, shipment intimations, and by responding promptly to customer complaints, the online merchant can make use of e-mail in improving the customer satisfaction.

Last but not the least, the online merchant should build trust among the customers. The goal should be building a reputation and not short-term profits. The shop should not engage in unfair trading practices. Cheating on prices, hiding the profits in exorbitant shipping charges, misleading the customers using currency conversion techniques, cheating the customer by displaying one product and then sending another, all these can bring in quick profits. But these strategies will definitely fail in the long run as the customers will soon find out these tricks and the word will spread like a bush fire (thanks to technology—e-mails, newsletters, newsgroups, bulletin boards, etc.) and soon the business will have to close.

INTERNET ECONOMY

So the ‘Internet Economy’ is really just the ‘Old Economy’ of setting up a business on a new street. Online retailers are still retailers. Sure it is a little different, they have to use technology and use it sensibly. But they have to follow the same business and economic rules as their brick and mortar peers. They still have to do research, plan, manage and finance carefully. They have to keep in mind the fact that the customers are their real assets and keeping the customers satisfied with quality products, bargain prices, good customer care, timely shipments, and fair and honest business practices is the secret for online success too.

THE FUTURE…

It is 2002. What is in store for the dotcoms? Is it all over for them? Yes the bubble has burst; the boom is long gone. The venture capitalists are not as enthusiastic and funding is difficult to get. Survey after survey predicts that the future is bleak for dotcoms. But there is still scope and hope for good business ideas. The dotcoms that plan their operations well, invest wisely in technology, manage the finances efficiently, promote effectively, sell high quality products or services and most importantly keep the customers happy and satisfied can still get off to a good start, buck the trend, thrive, survive, and grow.

Copyright © Alexis Leon. Reproduced with permission.