By Topic

Software, IEEE

Issue 6 • Date Nov 1995

Filter Results

Displaying Results 1 - 13 of 13
  • Implementing dialogue independence

    Page(s): 61 - 70
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (812 KB)  

    Separating the development of the core application from that of its user interface provides encapsulation, flexibility, and reuse advantages, but poses the problem of how to mirror changes to one component in the other. The authors identify three design patterns that achieve this mirroring while maintaining dialogue independence View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Programming in concurrent logic languages

    Page(s): 71 - 82
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (1168 KB)  

    The authors survey concurrent logic languages, which expand Prolog by dropping its built-in sequential search order. These languages make parallelism easy by avoiding the low-level constructs that result from a too direct translation of machine hardware into programmer's language View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Establishing a fair price for software

    Page(s): 105 - 106
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (180 KB)  

    The first step in determining software value is to determine the benefits that come from single-copy use. Software benefits can include enabling task completion, enhancing task quality, or improving efficiency. Obviously, not everyone experiences the same amount of benefit-if they derive a benefit at all. This means you must establish an average benefit for each user and quantify it in dollars. Second, the price a user is willing to pay for a software license is not equal to the anticipated benefit. In fact, the price must be typically a fraction of the benefit to justify the buyer's effort to acquire, install, learn, and maintain its operation. Clearly, some people pay more than others. You must decide whether to price for all market segments or only the upper end. Once you establish a price, multiply it by the estimated number of users. The result is the software's value, if the software has only one market or application. If there are multiple markets, apply this analysis to each individual market. The aggregate of all values for all markets represents the gross value. This is the value that gives a software developer bragging rights. However, the determination of gross value is only the first step in the search for the software's true value View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • SEL's software process improvement program

    Page(s): 83 - 87
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (440 KB)  

    We select candidates for process change on the basis of quantified Software Engineering Laboratory (SEL) experiences and clearly defined goals for the software. After we select the changes, we provide training and formulate experiment plans. We then apply the new process to one or more production projects and take detailed measurements. We assess process success by comparing these measures with the continually evolving baseline. Based upon the results of the analysis, we adopt, discard, or revise the process View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • What “lean and mean” really means

    Page(s): 101 - 102
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (228 KB)  

    Becoming lean means cutting salaries, trimming overhead, making the work place more spare, more crowded, and less comfortable. In short, it means making people's jobs less enjoyable in every conceivable way. If you find yourself working at a plastic desk in unnatural light, without proper clerical support, surrounded by bothersome noise, something is wrong, Your office at home, the place where you settle down for a few hours a month to pay your bills, is not as grim. Why would an organization provide for its people so much less than those people provide for themselves. There is a very good reason: the organization is failing. Becoming lean is not a sign of future health, but of present failure. The ultimate way to achieve leanness is downsizing, or, to put it more bluntly, firing lots of people more or less at random. Downsizing is exactly the opposite of what management has been chartered to achieve. The natural goal for almost any business is upsizing. Downsizing programs are clear admissions of upper management failure View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Web-based business process reengineering

    Page(s): 116 - 118
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (276 KB)  

    Software reengineering is not a widely accepted practice, but its methods and tools are critical to the success of business process reengineering (BPR). Reengineering software starts with an understanding of the existing system and an identification of those components that support the new business processes “as-is” and those that may have to be changed. Software reengineering would become widely used if the technology was more automated, more accessible and less complicated. Transformational reengineering encompasses available techniques for reverse engineering, reengineering and reuse, as well as the new medium of the World Wide Web (WWW). Using the WWW, the “as-is” and “to-be” designs can be made available for viewing and distribution. The author provides insight into the future of BPR and software reengineering using the WWW View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Critical reading for software developers

    Page(s): 103 - 104
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (184 KB)  

    Reading is no less important in the earlier stages of development, in requirements, analysis, specification, and design, where the descriptions are-or should be-more varied both in form and in content than they are in programming. One virtue of the SADT view of software development is its insistence on reading as well as writing the descriptions produced. In SADT, the business of reviewing what has been written is organized in the author/reader cycle. New views of mature ideas on software quality and productivity are presented View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • The 4+1 View Model of architecture

    Page(s): 42 - 50
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (696 KB)  

    The 4+1 View Model organizes a description of a software architecture using five concurrent views, each of which addresses a specific set of concerns. Architects capture their design decisions in four views and use the fifth view to illustrate and validate them. The logical view describes the design's object model when an object-oriented design method is used. To design an application that is very data driven, you can use an alternative approach to develop some other form of logical view, such as an entity-relationship diagram. The process view describes the design's concurrency and synchronization aspects. The physical view describes the mapping of the software onto the hardware and reflects its distributed aspect. The development view describes the software's static organization in its development environment View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Creating architectures with building blocks

    Page(s): 51 - 60
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (1052 KB)  

    Large systems need a sound architecture. In our method, we decompose the system into building blocks to make it “future-proof,” accommodate functional needs, and minimize system complexity. We organize the system construction along three design dimensions covered by the system architecture: structure, aspects, and behavior. The structure determines the system's decomposition into parts and the relationships between the parts. Aspects model the functional decomposition of the system. Behavior deals with processing that takes place within the system. Of the three dimensions, we consider structure to be the most important. In this dimension, reducing complexity is our main concern. We organize system functionality into four layers, or subsystems. These subsystems are composed of software modules-building blocks-which are the basic software entities in the system architecture View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Designing interfaces for the organization

    Page(s): 99 - 100
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (188 KB)  

    Multiuser systems force interface designers to consider a web of interacting users. Our challenge is to design interfaces that help users understand not only how the application program works, but also how work within the organization itself is done. Future organizational applications thus demand that interface design goes well beyond graphical representations and interactive dialogues. We must design interfaces that make relevant organizational resources comprehensible and accessible to users View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Comparing architectural design styles

    Page(s): 27 - 41
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (1192 KB)  

    Different architectural styles lead not simply to different designs, but to designs with significantly different properties. This look at 11 designs of a cruise-control system shows that solutions varied, even within a design style, because of how the architectural choice leads the designer to view the system's environment View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Architectural mismatch: why reuse is so hard

    Page(s): 17 - 26
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (940 KB)  

    Why isn't there more progress toward building systems from existing parts? One answer is that the assumptions of the parts about their intended environment are implicit and either don't match the actual environment or conflict with those of other parts. The authors explore these problems in the context of their own experience with a compositional approach View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Real programmers do use Delphi

    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (356 KB)  

    The author describes a career-journey that began with the maintenance of obsolete, poorly structured programs that came with almost no documentation. But he survived and moved on to work with and observe “real” programming practices in several companies. He describes how the “real” programming profession evolved and expanded into the mainstream of the software industry. E. Post's article “Real Programmers Don't Use Pascal” (Datamation, 1983) sent the overriding message that, despite the efforts of that day's quiche-eating programmers, real programming took real talent and, if done correctly, led to fun, wealth, and job security. Borland recently released a new, object-oriented version of Pascal called Delphi. It's far removed from the simplistic language Niklaus Wirth conceived; it's a pleasure to use, and it commands good contracting rates View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.

Aims & Scope

IEEE Software's mission is to build the community of leading and future software practitioners. The magazine delivers reliable, useful, leading-edge software development information to keep engineers and managers abreast of rapid technology change

Full Aims & Scope

Meet Our Editors

Editor-in-Chief
Forrest Shull
Fraunhofer Center for Experimental Software Engineering