Buy computer hardware houston software texas

Groupware, project management, Case tools help team buy time, control, better information

When we think of teams, we usually think of sports, not software development. Software developers have always worked in groups that could be defined loosely as teams, but only recently have developers begun to embrace the "team engineering" concept.

Football teams have an efficient, high-speed, interteam communications system--the huddle. By using it, each player knows what his function is and what he has to do. Although much of a player's functionality derives from the position he is playing, the team's strategy sessions pinpoint goals for specific situations. When the play begins, team members each have their own space to work in, although this space frequently overlaps.

Until now, software developers only had tools such as telephones, memos and conference rooms to expedite the flow of information between team members.

If the burgeoning market for team engineering tools is any indication, many information systems (IS) organizations are apparently game to work together. Team engineering tools run the gamut from electronic mail and project management, to full-blown repositories, to computer-aided software engineering (Case) tools with a decidedly team orientation. IS groups must decide which tool, or mix of tools, best suits the problem at hand.

Computer Associates International, Inc., Islandia, N.Y., is one vendor moving quickly into the team engineering marketplace with its PAN/LCM product, a life-cycle management library tool. According to Bill Clarke, director of product planning, workgroups require a set of robust features, such as "configuration management, source code control, versioning, a repository that supports concurrent access and consistency, and a set of tools such as compilers and editors."

Gupta Technologies, Inc., Menlo Park, Calif., has also joined the fray with its recent announcement of a product code-named Pegasus. According to Earl Stahl, vice president and general manager of Gupta's Desktop Products, the product "will provide a workbench from which to support multiprogrammer development for SQLWindows."

Case tool products have varying degrees of support for team engineering. Due to the networking capabilities of the Unix operating system, Case tools written for Unix development platforms have supported teams of developers using intelligent desktop machines longer than Case tools written originally for standalone PCs.

"Unix better enables communication among members of the team," said Geoffrey Barnes, national manager for the Software Engineering Productivity practice of Cap Gemini America, New York City. The U.S. arm of the Paris-based professional services provider uses tools from the following suppliers in its engagements: Texas Instruments, Plano, Texas; Knowledge Ware, Inc., Atlanta; Bachman Information Systems, Inc., Burlington, Mass.; IDE, San Francisco; and Cadre Technologies, Inc., Providence, R.I. The latter two have grown up on Unix development platforms; the others on non-Unix platforms.

Using Cadre's Teamwork in conjunction with the Process Weaver, a product Cap Gemini developed for process modeling and process support, "a work context gets passed from person to person, with all the inputs and expected outputs," Barnes said. From his experience, Barnes said Teamwork has been better at supporting a team of developers than the other products.

Groupware is another product category that is facilitating communications between development team members. The Canadian National Railway, located in Montreal, has been using Lotus Notes, from Lotus Development Corp., Cambridge, Mass., for about a year. From public affairs to credit management, the Canadian National Railway is installing Notes as project demand requires. Although user groups are clamoring for the sophisticated communications facilities of Notes, Canadian National Railway is finding the biggest payoff within the software development group.

Canadian National has recently translated its internal developmental methodology into Notes. "We have had a tremendously good response to this," said Ronan McGrath, the railway's vice president of information systems and accounting. Notes enables Canadian National's software developers to "look at all the project stages and project deliverables across development groups and comment on them."

GREATER INFORMATION SHARING

McGrath maintained the use of Notes has boosted development productivity. He said the rate of information cycling is much higher and, as a result, people are more current on the information they need to know. "It leads to a better quality product," he said.

Lotus' Holly Gunner, who heads the Business Reengineering Process Consulting Group, considers groupware to be integral to team engineering. The real purpose of team engineering, she said, "is to break down all the little walls between people and help them to work together better."

Gunner said one of the problems inherent in software engineering, at least in the past, has been that "serving a customer had been divided into little piece parts. You don't have people close to their work and able to see the whole flow and the results of their actions."

Gunner used Notes to get up to speed with the Lotus "team" after joining the firm in February. "There are people who have been here for years and know everyone. I don't. I can get into one of the Notes databases [though], and find lots of information."

Notes' messaging capabilities "provide the ability for a group to have many-to-many communications, as opposed to one-to-one," said McGrath, noting that the railway has 8,000 people on its network.

Tools are not the first thing an organization should look at, though, when embarking on team engineering. "Technology can help, but the first thing you have to do is to take a look at the business process, at the way the work is done, and scratch your head and ask some fundamental questions," said Gunner.

One important question is, "How can we get the software development process to be more akin to the engineering process?" Watts S. Humphrey has been asking, and answering, this question for many years. Humphrey spearheaded a team to create the Software Process Program of the Software Engineering Institute (SEI), located at Carnegie Mellon University in Pittsburgh. The role of the program is to provide leadership in establishing advanced software engineering processes, metrics, methods and quality programs. Today, with Humphrey as an SEI Fellow, the SEI team continues to augment and expand the precepts of managed software engineering.

Humphrey was previously associated with IBM, where he was responsible for IBM's commercial software development, including the first 19 releases of OS/360. He also managed IBM's Endicott, N.Y., development laboratory.

"The basic idea is to do software well," he said, adding that this may be organizationally impossible, at least in the short term. "You can't just do everything right away. Organizations are just muddling along and most [IS] organizations have learned to do software by the seat of their pants." Humphrey's theories on team engineering are presented in his book, Managing the Software Process (Addison Wesley, 1989).

Team management techniques do not come naturally to most. And a majority of IS managers do not have a disciplinary engineering background. So most IS people, according to Humphrey, learn to do software development "through the school of hard knocks."

Humphrey himself came up through the engineering ranks, gaining the experience necessary to build complicated systems. "You discover there are a few things you really have to do if you are trying to coordinate large numbers of people and do complex work," he said.

While Humphrey insists that software development should take on more of an engineering flavor, he admits that it is radically different from the engineering and manufacturing of a hardware component. "Manufacturing has a very natural discipline," he said. "You can't produce it unless you have a clean design. And you have to have some kind of a schedule to work with the factory. Otherwise, they won't be ready to work with you.

"There is a natural framework that requires the engineering community to have a rudimentary basic discipline or they won't be able to get their work done, period." There is no parallel natural discipline in the software world, he said.

SOFTWARE MATURITY FRAMEWORK

A framework for software development can be created, Humphrey said, but it involves hard work and a significant amount of time. While at SEI, Humphrey created the five-level software process maturity framework. The steps are: basic management control, process definition, process management, process control and optimizing process control.