The Tiers of Software Development

By -

The Tiers of Software Development

The lifecycle of software development continues to evolve, particularly with the advent of the object paradigm (discussed in Chapter 11). The lifecycle of development inevitably affects the way analysis and design are accomplished. Indeed, it seems only natural that the rapid changes in software methodologies would be accompanied by parallel development in analysis and design. Unfortunately, such is not the case, and the advances in software development continue to overshadow the importance of analysis and design.

As the software industry focuses on electronic commerce (e-commerce) through robust Web-based development, it becomes vitally important for the analyst to use the appropriate sequence of tiers to arrive at requirements. Developers cannot expect good results from taking shortcuts, tempting as it may be to do so. The recommended sequence of tiers is outlined below.

User Interface

Regardless of the type of software applications being developed, systems cannot be effectively designed without an appropriate user interface. The user interface tier acts as the foundation for the project: Without a solid foundation at this level, the project is at risk of collapsing at some point during development. Despite its importance, the user-interface tier is often overlooked: Many software projects today move too quickly into development without the effort having been spent to determine what is really needed from the user community. Successful analysts are aware of the critical importance of the user interface phase of any project. Chapter 3 focuses on methods of formulating user interfaces that can significantly improve software development.

Tools

Software systems require that analysts have the appropriate tools to do their job. Furthermore, an even more significant challenge is understanding which of the many available tools to use at any given point. Software development tools are often designed for specialized use rather than for general application, and using the wrong tool can potentially cause significant damage. Finally, the sequence of use for each specialized tool is also critical to success. Indeed, the order of operation, as well as the relationship among specialized analysis tools,

must be mastered to ensure success. Chapters 4 and 5 focus on which tools are needed to accomplish which tasks. The chapters also outline the advantages and disadvantages of each tool.

Productivity Through Automation

Having the appropriate tools and knowing how and when to use them is only part of the formula for success. Analysts must also be productive—and productivity can be accomplished only through the use of automation. Automation is imple- mented using integrated computer aided software engineering (CASE) products. These products provide the analyst with an automated and integrated toolbox of features that are centralized through a core data dictionary and repository.

Object Orientation

Successful projects employ the concepts of object orientation (OO). Whether or not software systems are OO compliant, analyzing systems using the object method builds better systems that are more cohesive, reusable, and maintainable (see Chapter 11). More cohesive code is “tighter” code, and is more easily fixed and maintained. It is also the foundation of the reusable components that can be incorporated into other applications later. Without the OO construct, systems tend to have pieces that are recoded and hard to maintain. With the advent of the enterprise solutions and e-commerce transactions that will be vital to business strategies, building object-based systems has become more a requirement than an option. However, as this book will show, businesses and organizations cannot just jump into OO, but rather they must create the foundations first through the previous tiers of development. Put another way, it is more important to understand the concepts of OO during analysis and design than it is to have the OO scheme actually programmed. This idea is discussed further in Chapter 11.

Client/Server

Today’s software is still governed by client/server processes. While client/server has become more widespread, it has not necessarily become better understood. As with the OO paradigm, client/server software development is often confused with network hardware strategy. While client/server hardware topology is an important issue in itself, it has little to do with the process of deciding how software modules should interact across the network and where such modules should be placed. Such decisions will be driven by issues that arise during the process of analysis. Client/server software processing, in its true implementation, involves the interaction of objects and defining the way in which they will

communicate with each other. Thus, analysts must first be versed in the laws governing OO if they are to pursue the client/server model. Incidentally, almost all Web-based applications that use JAVA, Active-X and other controls are designed essentially under the guidelines of interaction objects in a client/server environment.

Internet/Intranet

The advent of Web-based technology, sometimes known as Internet/Intranet processing, has led the industry to the use of a new breed of software applications. This new breed requires more robust processing and involves careful design and placement of pictures that provide users with a true “cafeteria” style of operation. These new applications bring new challenges to analysts and designers. Increasingly, it is not programmers who are designing the interface; rather, analysts themselves are beginning to work with commercial advertisers and marketing departments to create a “look and feel” that will be critical to the survival of many businesses. E-commerce, a result of the Internet/Intranet boom, represents another level of analysis. I believe that in the future, e-commerce will exert the strongest shaping influence on the analyst’s profession–a profession destined to become tomorrow’s integrators of systems development. Indeed, programming tools will continue to become easier to develop and more abundant in precoded forms. There will, undoubtedly, be less distribution of development teams, that is, companies will find more and more outsourced solutions to fill their needs. Notwithstanding the “automation” of code, the need for integrators who can communicate with executives and with line management and operations personnel will ultimately be the most significant forces in the development of strategic-based systems over the Internet.

Internet/Intranet processing requires that analysts have mastered the client/server paradigm. Indeed, many professionals have dubbed Internet development as “client/server grown up.” While this may or may not be the best definition of Internet/Intranet development, it is another statement that supports the tier concept, the concept that underlies the approach of this book.

This introduction is focused on presenting the steps necessary to success as a professional analyst. I call each of these steps tiers because of their building block nature and their dependencies on each other. I believe, therefore, that to learn to become an effective analyst, one must master the specifics within each of these tiers and must pass critical information to the next level. Rather than look at analysis sequentially, I would present the steps as levels as depicted in Figure 1.3.

The table graphically shows how each tier must be dependent on the other. There is a profound message in this diagram that suggests that no tier can be

clip_image002

Figure 1.3 Tiers of analysis and software application development.

developed or exist without the previous one. To ensure success on a project, everyone involved in the design and development of application software must fully understand the interdependent nature of these tiers. Analysts must be able to convey to their colleagues that to do Internet/Intranet development, organizations must first have excellent user interfaces, mastery of a structured toolset, a vehicle for automation so that the process will be productive, an understanding of the concept of objects, and a way to deploy these objects in a client/server environment. It all sounds so simple, and in many ways it is. The question answered by this new edition is how?

Problems and Exercises

1. Professionals often refer to software projects as being very complex.

Explain why this complexity might be overstated and misunderstood.

2. What is a Gantt chart? How are Gantt charts used and why is it important that they be realistic estimates of how the project will proceed?

3. Explain what is meant by “tiers of software development.”

4. The user interface represents the first critical step to obtaining the proper needs of users. Provide five examples of different user positions that might be critical to interview.

5. Discuss the importance of using the appropriate analysis tool when interviewing users and building specifications.

6. How is productivity obtained in analysis? What tool is best used?

7. Explain why object orientation is beneficial to software developers.

8. What is the use of client/server with respect to software development?

9. Why is Internet/Intranet processing so important to today’s Web development?

Comments

Post a Comment

Popular posts from this blog

WORKED EXAMPLES ON PROCESS SPECIFICATION.

By -
Image
PROCESS SPECIFICATION WORKED EXAMPLES 6.1 A bank has the following policy on deposits: On deposits of Rs. 5000 and above and for three years or above the interest is 12%. On the same deposit for a period less than 3 years it is 10%. On deposits below Rs. 5000 the interest is 8% regardless of the period of deposit. Write the above process using (i) Structured English (ii) A decision table 6.2 An organization maintains an employee file in which each record has following data: { Employee No., employee name, employee gross pay}. It has been decided to increase the pay as per the following formula: For pay of Rs. 1000 or less increase 15%. For pay of more than Rs. 1000 but up to Rs. 2500 increase 10%. For pay over Rs. 2500 increase 5%. (i) Writ e a structured English processing rule corresponding to the above policies. (ii) Express the policies as a decision table. (i) While employee records left in file do Read Number, name , gross pay 6.3 An offshore gas company bills it
Read more

Why do we need information systems, management structure, requirements of information at different levels of management.

By -
Image
Why do we need information systems, management structure, requirements of information at different levels of management NEED FOR INFORMATION SYSTEMS Information systems are needed when timely processing for fast action is needed, same data has to be processed in different ways and when organizations require innovative processing. MANAGEMENT STRUCTURE Functional areas of management are as follows: •PRODUCTION • MARKETING • MATERIALS – purchase, stores • FINANCE –Accounts • HUMAN RESOURCE DEVELOPMENT(HRD) • RESEARCH AND DEVELOPMENT (R&D) INFORMATION FOR MANAGEMENT A Production Management The following type of information is needed in production management: Strategic Information: 1)Yearly and monthly production quotas and alternate schedules 2)Policies on machine replacement, augmentation and modernization. 3)Identifying best product mix. Tactical Information 1)Identifying and controlling areas of high cost. 2) Identifying critical bottlenecks in production. 3)
Read more

The User Interface:Establishing User Interfaces

By -
Image
The User Interface Establishing User Interfaces The success factors in analysis start with the established interfaces from day one. What does this mean? You must start the process by meeting with the right people in the organization. In the best projects, the process is as follows: 1. Executive interface: There needs to be an executive-level supporter of the project. Without such a supporter, you risk not being able to keep the project on schedule. Most important, you need a supporter for the political issues that you may need to handle during the project (discussed in detail later). The executive supporter, sometimes known as a sponsor (JAD reference), should provide a preliminary schedule advising the organization of what is expected and the objectives of the project. The executive supporter should attach a letter to the preliminary schedule and send it to the project team members. The letter must put the importance of the project into perspective. Therefore, it is strongly rec
Read more