Software Engineering for Students A Programming Approach
Share Embed Flag
Download ePaper

Software Engineering for Students A Programming Approach

Software Engineering for Students A Programming Approach Software Engineering for Students A Programming Approach

web.firat.edu.tr
from web.firat.edu.tr More from this publisher
21.08.2013 Views

28.6 The object-oriented team 353 The benefits of the chief programmer team to the organization are thus: (a) improved programmer productivity because ■ less time is spent in communication ■ each programmer is carrying out specialized work at which they are highly skilled (b) improved software quality because ■ the team is organized around a highly skilled programmer ■ the interfaces between software components are clearer ■ fewer bugs arise from communication problems because there are fewer programmers (c) meeting deadlines more reliably because ■ there is greater visibility of the project through the high technical involvement of the chief programmer. Other benefits that are cited concern career paths. Someone who is a good programmer but does not want to go into management can become a chief programmer – largely a technical role. A number of problems arise for the management of a large project. First, since any team is only manageable with up to about nine people, what do we do if a project is sufficiently large that it needs more than this number? One suggestion (but it is only that) is to start the project with a chief programmer team to carry out the high-level software design and the top-level implementation. When this is complete the original team is broken up and its members become chief programmers within the set of teams that carry out developments of the subsystems. A remnant of the original team carries out system integration and validation. Another problem of chief programmer team organization is this: the team is supposed to be made up of good experienced programmers, so how do inexperienced programmers gain expertise? Here the suggestion is that they train by doing maintenance on existing programs. 28.6 ● The object-oriented team Object-oriented development tries to achieve two objectives: ■ reuse of existing components from either the standard library or the in-house library ■ the creation of new reuseable components for the in-house library. Thus, organizations using the object-oriented paradigm have found it desirable to divide their personnel into teams of application programmers on the one hand, and teams of class or component programmers on the other. The motivation here is that the

354 Chapter 28 ■ Teams benefits of the object-oriented paradigm are only be realized if a concerted effort is made to identify reusable software components and to organize such components within an accessible library. A domain-specific class library becomes viewed as one of the major assets of the organization. Indeed, some large companies have reported that they have been able to reduce the amount of new code written on large projects by a factor of 50% through the use of such libraries. In such a scenario, application programmers are thought of as consumers; they implement application-specific classes, but are always seeking to reuse existing library components whenever possible. They seek better reusable components from the class programmers and also have a responsibility to identify useful abstractions that can be migrated from the application to the library. Class programmers (or component developers) are thought of as producers; they produce reusable components of general use to the organization. Their job is to polish, generalize, reorganize and augment library classes. Their task should not be underestimated – producing reusable components is more difficult than writing components for a specific project. In a moderate-size project the developers are divided up along class versus application lines. The architecture team contains the key designers and programmers; their responsibility is to oversee the project as a whole and also to take responsibility for critical modules of the system. They are supported by teams of subsystem developers who are responsible for the development of “large grain” subsystems. The class developers are responsible for the development of a reusable component library. This kind of approach has given rise to a plethora of new job titles and functions, for example, application directors, class managers, reuse evaluators. The key to the success of such an approach is communication between team members, particularly between the architecture/subsystem teams and the component developers. It is highly desirable to develop a culture in which team members are rewarded for producing components that have a broad applicability or design frameworks that can be reused. 28.7 ● Discussion The chief programmer team is hierarchical and tree-structured. Its organizational structure tends to produce software that has a matching structure. This may be completely appropriate for certain types of software. Indeed, much software is hierarchical in structure. Generalizing, it can be hypothesized that teams tend to produce software whose structure matches their own structure. Suppose, for example, that some software is designed by a committee, acting democratically. What would the structure of the software look like? Perhaps it would be complex, with many interactions (reflecting the many interactions between its designers) or perhaps it would display haphazard structure, without the single clear vision provided by a charismatic leader. But for certain types of software – for example, expert systems – these structures might be completely appropriate. Thus it may be that different forms of organization are appropriate for different types of software project.

28.6 The object-oriented team 353<br />

The benefits of the chief programmer team to the organization are thus:<br />

(a) improved programmer productivity because<br />

■ less time is spent in communication<br />

■ each programmer is carrying out specialized work at which they are highly<br />

skilled<br />

(b) improved software quality because<br />

■ the team is organized around a highly skilled programmer<br />

■ the interfaces between software components are clearer<br />

■ fewer bugs arise from communication problems because there are fewer programmers<br />

(c) meeting deadlines more reliably because<br />

■ there is greater visibility of the project through the high technical involvement<br />

of the chief programmer.<br />

Other benefits that are cited concern career paths. Someone who is a good programmer<br />

but does not want to go into management can become a chief programmer – largely<br />

a technical role.<br />

A number of problems arise <strong>for</strong> the management of a large project. First, since any<br />

team is only manageable with up to about nine people, what do we do if a project is<br />

sufficiently large that it needs more than this number? One suggestion (but it is only<br />

that) is to start the project with a chief programmer team to carry out the high-level<br />

software design and the top-level implementation. When this is complete the original<br />

team is broken up and its members become chief programmers within the set of teams<br />

that carry out developments of the subsystems. A remnant of the original team carries<br />

out system integration and validation.<br />

Another problem of chief programmer team organization is this: the team is supposed<br />

to be made up of good experienced programmers, so how do inexperienced programmers<br />

gain expertise? Here the suggestion is that they train by doing maintenance<br />

on existing programs.<br />

28.6 ● The object-oriented team<br />

Object-oriented development tries to achieve two objectives:<br />

■ reuse of existing components from either the standard library or the in-house library<br />

■ the creation of new reuseable components <strong>for</strong> the in-house library.<br />

Thus, organizations using the object-oriented paradigm have found it desirable to<br />

divide their personnel into teams of application programmers on the one hand, and<br />

teams of class or component programmers on the other. The motivation here is that the

logo

products

Resources

Company

Terms of service
Privacy policy
Cookie policy
Cookie settings
Imprint
Change language
Made with love in Switzerland
© 2024 Yumpu.com all rights reserved

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!