Jacobson, I., Griss, M., Jonsson, P., Software Reuse. Architecture, Process and Organization for Business Success, Addison-Wesley, ISBN: 0-201-92476-5, 1997.  Home/Search   Document Not in Database   Summary   Related Articles   Check

.... [130] The productivity of software development can be increased because for the development of a new system not all software needs to be developed from scratch but existing artifacts can be used (as is) 103] The quality of software can be increased because proven technology can be reused [73]. Software reuse is not limited to source code fragments, but may include documentation, specification, design structures and so on [61, 92] In this thesis we concentrate on reuse of source code fragments and of pre compiled units such as executable programs and libraries. The fundamental unit ....

....allows for maximal reuse of code. We implemented the customer specific mechanism in JAVA. It could easily be implemented in other languages as well. 7.6. 2 Related work RSEB, the Reuse driven Software Engineering Business covers many organizational and technical issues of software product lines [73]. They emphasize an iterative process, in which an application family evolves. Variation points are distinguished both at the use case and at the source component level. Components are grouped into component systems, which are similar to our abstract packages. In certain cases component systems ....

I. Jacobson, M. Griss, and P. Jonsson. Software Reuse: Architecture, Process and Organization for Business Success. Addison-Wesley, 1997.

....sector. This has often been accompanied by techniques, such as statistical analysis, data mining like that provided by rough sets [21] or AI oriented methods like case based reasoning [10] Finally, we can mention initial work on use of OO style patterns to represent reusable classes of projects [8]. More recently [9] proposes a systematic method for risk management, where risk is seen as variance or degree of imprecision. The idea of risk scenarios (the hierarchy of risk factor risk event reaction) is adapted in this paper to systematically make planning decisions about how to deal ....

Ivar Jacobson, Martin Griss, and Patrick Jonsson. Software Reuse: Architecture, Process and Organization for Business Success. ACM Press / Addison Wesley Longman, New York / Reading, Massachusetts, 1997.

....modelling in application, navigation and presentation design. Finally, we give conclusions and proposal for further work. 2 Background Domain Engineering vs. Application Engineering Domain engineering concentrates on providing reusable solutions for families of systems. According to [15], the domain engineering is a systematic way of identifying a domain model, commonality and variability, potentially reusable assets, and an architecture to enable their reuse. The idea behind this approach to reuse is that the reuse of components between applications occurs in one or more ....

.... relationships for its subfeatures, is denoted as a variation point [21] or variation [11] Feature diagrams are the key part of the feature modelling in methods such as MBSE [21] or generative programming [5] UML is employed for example in Reuse Driven Software Engineering Business (RSEB) [15, 11]. Variability points are considered in the use case view and the component view in [15] The variability modelling in the conceptual view is discussed in [11] In this work the extension for features, their attributes and variation points is de ned. The attributes can be suppressed in the model. ....

[Article contains additional citation context not shown here]

Ivar Jacobson, Martin Griss, and Patrik Jonsson. Software Reuse: Architecture, Process and Organization for Business Success. ACM Press, 1997.

.... notion of constructing software systems by composing software components and a family of software products is not recent [23] 25] Combining both concepts has resulted in approaches towards software design that share the ability to delay design decisions to a later phase in the development process [19][20] The recent emerge of software product lines provides an example of delayed design decisions. The core idea of software product line engineering is to develop a reuse infrastructure that supports the software development for a family of products. The differences between the products express ....

....hand, relates to adapting the product line architecture to fit the system architecture of the product in question. In other words, the product line domain is divided in reusable and non reusable assets, i.e. domain and application engineering, respectively. This approach is also taken in, e.g. [19]. Variability in software product lines can be observed in two dimensions [8] viz. space (e.g. software artifacts appear in several products) and time (i.e. software artifacts change over time) Features are suggested as a useful abstraction to express variability [18] in both dimensions, ....

[Article contains additional citation context not shown here]

I. Jacobson, M. Griss, P. Jonsson. Software Reuse - Architecture, Process and Organization for Business Success. Addison-Wesley, 1997.

.... they are also commonplace in for instance the car, the airplane and the food industry [8] Most software product line research focuses on an early analysis of commonality and variation [1] followed by the creation of a variant free architecture [25] with a sufficient number of variation points [13] to deal with diversity. While this works well for small product families in a small organization, we have experienced problems when applying this to larger ranges of products, especially when development crosses organizational boundaries. This paper is about widening the scope of product lines ....

Ivar Jacobson, Martin Griss, Patrick Jonsson, Software Reuse -- Architecture, Process and Organization for Business Success, Addison Wesley, New York, 1997, ISBN 0-20192476 -5.

....these definitions a software product line can be seen as an engineered product family where each product is launched, sold, and shipped seperately. 6 1.3 Expected Benefits Reuse of high level artifacts is the main objective of the product line development approach. As stated by Jacobson et al. [JGJ97] reuse strategies have three major goals: Faster development Time to market has become a crucial factor for being successful in todays software markets. Reusing artefacts leads to shorter development times because products are not build from scratch each time. Improved quality Only ....

....decrease. The same holds for the maintenance costs since only the product specific aspects must be developed and maintained separately. By consequently applying reuse strategies in all development areas noticeable improvements can be achieved. Jacobson et al. report the following improvements [JGJ97]: Factor 2 to 5 faster time to market Factor 5 to 10 less error sensibility Factor 5 to 10 less maintenance costs The overall development costs are reduced of around 15 to as much as 75 for long term projects. Furthermore, the application of reuse strategies creates highly adaptable ....

Ivar Jacobson, Martin Griss, and Patrik Jonsson. Software Reuse, Architecture, Process and Organization for Business Success. Addison Wesley, 1997.

....in a combinatorial number of classes with no reuse at all. In order to prevent this, the variabilities of a component must be controlled more systematically also at the implementation level. For that purpose, variability mechanisms are needed. 3 Variability Mechanisms A variability mechanism [5] is a way of implementing varying characteristics of a component at the implementation level. Goals of variability mechanisms are to minimize code duplication, reuse e#ort, and maintenance e#ort. One at a time Implementation Product Line Concepts Generic Component Implementation ....

I. Jacobson, M. Griss, P. Jonsson: Software Reuse: Architecture, Process and Organization for Business Success. Addison-Wesley, 1997

....them have to ensure that every iteration of the development process leads to progress in terms of functionality without loss in terms of software quality. To control projects, models for software development processes have been introduced. Waterfall like models have proven inadequate in practice [9]. Therefore, iterative process models, such as the spiral model, have been developed. Below, a development process model is shown, which: has been adapted with respect to the characteristics of object oriented design using the UML and . focuses on use cases models and architectural ....

....Below, a development process model is shown, which: has been adapted with respect to the characteristics of object oriented design using the UML and . focuses on use cases models and architectural decisions. The following important properties of software development processes (e.g. [9]) are taken into consideration by this model: The processes are iterative and consist of increments or milestones (the progress of projects has to be visible) They are evolutionary and should be event oriented (reacting to new requirements) An iterative model for software development ....

Jacobson, I., Griss, M., Jonsson, P.: Software Reuse - Architecture, Process and Organization for Business Success, Addison Wesley (1997).

....Finally, results and achievements are described along with some refinements carried out to the final solution. Keywords: re engineering, re platforming, software maintenance, client server process. 1. CONTEXT The Application re engineering is aimed at valorizing pre existing software systems [1], thus representing a significant and often irreplaceable asset for a company, but no longer meeting the requirements of economy and quality during the maintenance life cycle. Apart from other benefits, the application re engineering service allows: valuable reduction in maintenance costs; ....

I. Jacobson, M. Griss, P. Jonsson -- Software Reuse, Architecture, Process and Organization for Business Success, Addison Wesley Longman 1997 - ISBN 0-20192476 -5.

....design. Objectoriented implementations provide a high amount of correctness, robustness, ex tendability, reusability and maintainability [MEY88] Quoting Jacobson, Griss and Jonsson the concept of objects has turned out be ideal for representing most elements within the various software models [JAC97]. So I decided to create an object oriented design for Web Enterprise. 11 Since the simulation algorithms in Enterprise have been used for many years without any problems they can be classified to be correct. It made sense to integrate them in the new version. A migration from a classic software ....

Jacobson, I., M. Griss, P. Jonsson, Software Reuse, Architecture, Pro- cess and Organization for Business Success, ACM Press, 1997

....and allows for maximal reuse of code. We implemented the customer specific mechanism in Java. It could easily be implemented in other languages. 6. 2 Related Work RSEB, the Reuse driven Software Engineering Business covers many organizational and technical issues of software product lines [13]. They emphasize an iterative process, in which an application family evolves. Variation points are distinguished both at the use case and at the source component level. Components are grouped into component systems, which are similar to our abstract packages. In certain cases component systems ....

I. Jacobson, M. Griss, and P. Jonsson. Software Reuse: Architecture, Process and Organization for Business Success. Addison-Wesley, 1997.

....a system or an external system. A use case can be defined as a specific way of using the system by performing some part of the functionality, and it includes preconditions, flow of events, and post conditions. A use case model is closest to the requirements, and with the least amount of detail [11]. Therefore, most business objects required by the system can be identified from the output of the Identify Use Case activity. 3.3 Goal Identification The identified use cases are fed to the activity Identify Goals in Figure 2 for capturing goals . A goal is an objective or a desired state ....

Jacobson, I., Griss M., and Jonsson P. Software Reuse - Architecture. Process and Organization for Business Success, ACM Press, (1997).

....with the platform project leader and the platform manager. At the other hand he needs many architectural contacts with the product family architect, acting as the architectural principal, with the product architect, acting as customers and with the component architects, acting as suppliers. In [1] 3 operational entities with related processes and roles are identified, see table 2. The operational entities from figure 6 are shown in the last column, although other mappings are possible too. Any mapping has the problem that 4 operational entities are represented in only 3 processes in [1] ....

....In [1] 3 operational entities with related processes and roles are identified, see table 2. The operational entities from figure 6 are shown in the last column, although other mappings are possible too. Any mapping has the problem that 4 operational entities are represented in only 3 processes in [1]. In practice the result is that one of the roles is missing, or played implicit. For instance quite often the application family engineer starts to play platform architect, forgetting his original task application family engineering. Gerrit Muller PCP operational manager Family operational ....

Ivar Jacobson, Martin Griss, and Patrik Jonsson. Software Reuse; Architecture, Process and Organization for Business Success. ACM Press, New York, 1997.

....with the platform project leader and the platform manager. At the other hand he needs many architectural contacts with the product family architect, acting as the architectural principal, with the product architect, acting as customers and with the component architects, acting as suppliers. In [7] 3 operational entities with related processes and roles are identified, see table 11.2. abbreviation description maps to operational entity AFE Application Family Engineering Product Family CSE Component System Engineering Component ASE Application System Engineering Product Platform ....

....Process Generic Something Creation Process Figure 11.5: Feedback and Value flow The operational entities from figure 11.6 are shown in the last column, although other mappings are possible too. Any mapping has the problem that 4 operational entities are represented in only 3 processes in [7]. In practice the result is that one of the roles is missing, or played implicit. For instance quite often the application family engineer starts to play platform architect, forgetting his original task application family engineering. 11.5 Models for Generic Developments Many different models ....

Ivar Jacobson, Martin Griss, and Patrik Jonsson. Software Reuse; Architecture, Process and Organization for Business Success. ACM Press, New York, 1997.

....and allows for maximal reuse of code. We implemented the customer specific mechanism in Java. It could easily be implemented in other languages. 6. 2 Related Work RSEB, the Reuse driven Software Engineering Business covers many organizational and technical issues of software product lines [13]. They emphasize an iterative process, in which an application family evolves. Variation points are distinguished both at the use case and at the source component level. Components are grouped into component systems, which are similar to our abstract packages. In certain cases component systems ....

I. .Jacobson, M. Griss, and P. Jonsson. Software Reuse: Architecture, Process and Organization for Business Success. Addison-Wesley, 1997.

....objects) are similar. The mechanism of these interactions is composed of the following main steps: 1) publishing, sharing and knowledge of agent identifiers; 2) acquisition of references to agents; and (3) invocation of agents final methods, some of which have a higher level of variability [JGJ97], such as sendMessage , doOperation getManagementInterface, or moveTo . 4.3 Relationship with the MVC Architecture The model view controller (MVC) architecture was originally used to build flexible user interfaces in Smalltalk 80 [KP88] It defines a trend on modern object oriented frameworks. ....

Ivar Jacobson, Martin Griss , Patrik Jonsson. Software Reuse -- Architecture, Process and Organization for Business Success. Addison Wesley, 1997.

....features. FODA offers a high level view onto a product line with the concepts of commonality and variability. There is no connection between requirements and features. Furthermore, FODA is not intended for cooperation with objectoriented methods. Reuse driven Software Engineering Business (RSEB) [11] is a method based on object technology with a use case driven characteristic. RSEB uses a reference architecture for reusing components. Graphical notations are based on UML, with variation points added to define variable parts and to connect them to model elements. However, the combination of ....

I. Jacobson, M. Griss, P. Jonsson, Software Reuse -- Architecture, Process and Organization for Business Success. Addison-Wesley-Longman, 1997.

....used in domain analysis to depict mandatory and variant requirements. Feature models must be complemented with other notations, for example UML, to enhance the meaning of domain concepts. Notations traditionally used in requirement analysis can be extended with the concept of a variation point [8] to make them useful in domain modeling. In our early work, we extended notations of DFD, ER and STD with variants [4] Modeling variants adds an extra level of complexity to domain analysis, otherwise similar to requirement analysis for a single system. Tracing multiple occurrences of the same ....

....variant requirements [3] Unlike feature diagrams, design spaces do not show variant types (e.g. optional, alternative and orrelationship) or depict structural relationship among variant requirements . UML notations may be extended with variation points to cater for variant requirements [8] . A generic software model (analysis component) is customized by attaching one or several variants to its variation points. In analogical domain analysis [11] one attempts to build abstract models for problems that recur in different application domains . Abstract models are then instantiated ....

Jacobson, I. M. Griss and P. Jonsson Software Reuse Architecture, Process and Organization for Business Success, Addison-Wesley, 1997

....the different ODP viewpoints to UML diagram types as depicted in Fig. 2 [KTW97] has been adopted in the TRUMPET project. The major benefit of such a mapping consists in supporting both an object oriented modelling and design process, and the design of reusable components and distributed services [JAC97] in the sense of distributed systems as described in the Reference Model for Open Distributed Processing (RM ODP) ISO95] ODP defines clearly the concept of viewpoints, and it provides several different viewpoint languages, which may be unified using UML notations and concepts for specifying all ....

Ivar Jacobson, Martin Griss, and Patrik Jonsson, Software Reuse: Architecture, Process and Organization for Business Success. Addison-Wesley,1997.

.... Process definitions have to state which techniques are appropriate at various levels of detail during development, which deliverables have to be produced, who should produce them, and which inspections, standards, metrics, and tests should be used to control quality and certify system correctness [1,13]. A UML based process for systems development founded on the business object paradigm must span the whole range from business engineering (using business object models) to application engineering (with an emphasis on reusing pre built business object software components) and business object ....

....business object components for reuse. This activity may be independent of a concrete application engineering process. Similar distinctions between these two kinds of processes can be found in several approaches: 1] for example, distinguish between solution projects and component projects, while [13] speak of application system engineering and component system engineering. The normal course of activities begins with a business engineering process as the starting point, followed by a system architecture engineering process. When the system architecture is defined, several application ....

[Article contains additional citation context not shown here]

Jacobson, I., Griss, M. and Jonsson, P. (1997): Software Reuse -- Architecture, Process and Organization for Business Success. Addison Wesley Longman, Harlow, England.

....of object technology. One of the key lessons of the first phenomenon, progress in the research in systematic software reuse, is that substantial benefits of component technology can only be achieved by concentrating on a particular application domain [18, 21] As an example, Jacobson et al. [14] sketch the steps that a typical organization may go through 9 when adopting component technology: an organization starts with informal code reuse leading to some reduction in development, and step by step gets closer to the domainspecific reuse driven organization, which is capable of rapid ....

I. Jacobson, M. Griss, and P. Jonsson. Software Reuse; Architecture, Process and Organization for Business Success. Addison Wesley, 1997.

....The Rational Unified Process activities create and maintain models. Rather than focusing on the production of large amount of paper documents, the Unified Process emphasizes the development and maintenance of models semantically rich representations of the software system under development. [3, 7, 8] The Rational Unified Process is a guide for how to effectively use the Unified Modeling Language (UML) The UML is a industry standard language that allows us to clearly communicate requirements, architectures and designs. The UML was originally created by Rational Software, and is now ....

Ivar Jacobson, M. Griss, and P. Jonsson, Software Reuse---Architecture, Process and Organization for Business Success, Harlow, England, AWL, 1997.

....problems. Consequently, its complexity has increased as well. Understanding and maintaining software is both difficult and expensive. The object oriented community has been exploring ways to keep complexity and costs under control. Things like reuse software engineering are becoming a business [JGJ97] However, these techniques are hopeless without a good understanding of the problem, its solution and the available alternatives. 1 A workflow facility brings together principles, methodologies and technologies from various areas of computer science and management science [Moh97] ....

Ivar Jacobson, Martin Griss, and Patrik Jonsson. Software Reuse---Architecture, Process and Organization for Business Success. ACM Press Books. Addison-Wesley, 1997.

.... are appropriate at various levels of detail during development, which deliverables have to be produced, who should produce them, and which inspections, standards, metrics, and tests should be used to control quality and certify system correctness (Allen and UML 98 3 Frost 1998, Jacobson et al. 1997). In order to use UML for systems development based on the business object paradigm, a process has to be defined which spans the whole range from business engineering (using modeling business objects) to application engineering (with an emphasis on reusing pre built systems business objects in the ....

....for reuse. This activity may be independent of a concrete application engineering process. Similar distinctions between these two kinds of processes can be found in several approaches: Allen and Frost (1998) for example, distinguish between solution projects and component projects, while Jacobson et al. 1997) speak of application system engineering and component system engineering. The normal course of activities begins with a business engineering process as the starting point, followed by a system architecture engineering process. When the system architecture is defined, several application ....

[Article contains additional citation context not shown here]

JACOBSON, I., GRISS, M., and JONSSON, P. (1997): Software Reuse -- Architecture, Process and Organization for Business Success. Addison Wesley Longman, Harlow, England.

....to automatically customize components, the development of software systems can thus be automated at least partially. During system development, reusable artifacts have to be explicitly considered, and the development process has to be tailored to appropriately reflect the reuse based approach [7][15] Reuse activities such as component selection and configuration have to be modeled as separate process steps rather than being performed under the hood of conventional development steps. In contrast to sporadically searching for reusable assets to implement a particular functionality, the ....

Jacobson, I.; Griss, M.; Jonsson P.: Software Reuse - Architecture, Process and Organization for Business Success, ACM Press/Addison-Wesley, 1997

.... Reuse It is commonly accepted that ad hoc reuse of components is far from exploiting the inherent potential, and that in many cases it may even be detrimental to the realization of a software project [5,6] To foster component reuse, specifically tailored development processes have to be provided [11,19], which explicitly consider reuse aspects and reuse specific activities in the various stages of the development process. For example, component selection, configuration, and composition have to appear as independent activities instead of being performed under the hood of conventional subprocesses ....

Jacobson, I.; Griss, M.; Jonsson P.: Software Reuse - Architecture, Process and Organization for Business Success, ACM Press/Addison-Wesley, 1997

No context found.

I. Jacobson, M. L. Griss, and P. Jonsson. Software Reuse: Architecture, Process and Organization for Business Success, Addisson-Wesley, 1997.

No context found.

I. Jacobson, M. Griss, and P. Jonsson. Software Reuse: Architecture, Process and Organization for Business Success, Addison-Wesley, 1997.

....of each component only depends on interfaces and has no assumption of internal working of other components. This fact implies that the impact of changes only propagates through the dependency of interfaces. Thus, carefully designed component architecture can manage the impact of changes effectively[6]. Since the time to market of products becomes the key consideration in development, the robustness of architecture takes more attentions. Unfortunately, most efforts on component architectures have considered IT area only[2] The purpose of this paper is to introduce the idea of robust component ....

I. Jacobson, M. Griss, and P. Jonsson. Software Reuse: Architecture, Process and Organization for Business Success. Addison-Wesley, 1997.

....process 0 7803 6424 4 00 10.00 2000 IEEE October 18 21, 2000 Kansas City, MO related, business oriented, infrastructure, organizational and management issues. Resolving those issues requires a systematic approach to building component based reusedriven software engineering business [6,7]. That is why software engineers need to acquire a new set of skills. This has introduced the need for a new course sequence that integrates CBESE into the software and information engineering curriculum [8,9] INTEGRATING COMPONENT BASED REUSEDRIVEN SOFTWARE ENGINEERING BUSINESS INTO THE ....

....of engineering, business oriented, process related, organizational, and management issues that block or hinder transition from traditional software engineering to component based enterprise software engineering. The students also learn a framework called Reuse driven Software Engineering Business [6], developed to resolve the key issues in a systematically. The approach has been credited for success of several large companies including Ericsson and Hewlett Packard in transitioning from traditional software engineering to component based and reuse driven software engineering. The course ....

[Article contains additional citation context not shown here]

. Jacobson, I., Griss, M. and Jonsson, P., Software Reuse: Architecture, Process and Organization for Business Success, Addison Wesley, 1997.

....engineering techniques, OO methods, and organizational design to our corporate reuse programs and to customer reuse efforts. In 1997 we published a book on the Reuse Driven Software Engineering Business (RSEB) with partners from Rational Software Corporation, describing our systematic approach [1]. At Intecs Sistemi we have been involved for many years in the development of OO and reuse design tools [2] for industrial and aerospace applications [3] Over the past two years we have been involved in a customization of the Feature Oriented Domain Analysis (FODA) 4] method for applications in ....

....leading to application engineering [7] The kinds of features that can be considered has been enriched, explicitly distinguishing those related to user visible functionality, from those related to implementation issues. 2.3. RSEB The Reuse Driven Software Engineering Business (RSEB)[1] is a systematic, model driven approach to large scale software reuse. RSEB is based on Jacobson s OO Software Engineering[8] and OO Business Engineering[9] applied to an organization engaged in building sets of related applications from sets of reusable components. Explicit use case models are ....

[Article contains additional citation context not shown here]

I Jacobson, M Griss, P Jonsson, Software Reuse: Architecture, Process and Organization for Business Success, AddisonWesley -Longman, May 1997.

No context found.

Jacobson, I.; Griss, M.; Jonsson P.: Software Reuse - Architecture, Process and Organization for Business Success, ACM Press/Addison-Wesley, 1997

....to automatically customize components, the development of software systems can thus be automated at least partially. During system development, reusable artifacts have to be explicitly considered, and the development process has to be tailored to appropriately reflect the reuse based approach [8][16] Reuse activities such as component selection and configuration have to be modeled as separate process steps rather than being performed under the hood of conventional development steps. In contrast to sporadically searching for reusable assets to implement a particular functionality, the ....

Jacobson, I.; Griss, M.; Jonsson P.: Software Reuse - Architecture, Process and Organization for Business Success, ACM Press/Addison-Wesley, 1997

No context found.

JGJ97 Jacobson I., Griss M., Jonsson P., Software Reuse --- Architecture, Process and Organization for Business Success. Addison-Wesley, 1997.

No context found.

Jacobson, I., Griss, M., Jonsson, P., Software Reuse. Architecture, Process and Organization for Business Success, Addison-Wesley, ISBN: 0-201-92476-5, 1997.

No context found.

Ivar Jacobson, Martin Griss, and Patrik Jonsson. Software Reuse: Architecture, Process and Organization for Business Success. ACM Press. Addison-Wesley, 1997.

No context found.

I. Jacobson, M. Griss, P. Jonsson. Software Reuse: Architecture, Process and Organization for Business Success. Addison-Wesley. 1997

No context found.

I. Jacobson, M. Griss, and P. Jonsson. Software Reuse: Architecture, Process and Organization for Business Success. Addisson-Wesley, 1997.

No context found.

I. Jacobson, M. Griss, P. Jonsson, Software ReuseArchitecture, Process and Organization for Business Success. ACM Press, New York, NY, 1997.

No context found.

Jacobson, I.; Griss, M.; Jonsson, P. Software Reuse: Architecture, Process and Organization for Business Success. Addison-Wesley, Reading, Massachusetts, June 1997.

No context found.

I. Jacobson, M. Griss, and P. Jnsson, Software Reuse: Architecture, Process and Organization for Business Success, Addison-Wesley, 1997.

No context found.

Jacobson, I., Griss, M. and Jonsson, P. Software Reuse: Architecture, Process and Organization for Business Success. ACM Press, New York, NY, 1997.

No context found.

Ivar Jacobson, Martin Griss, Patrik Jonsson, Software Reuse: Architecture, Process and Organization for Business Success, Addison-Wesley-Longman, May 1997.

No context found.

Ivar Jacobson, Martin Griss, and Patrik Jonsson. Software Reuse; Architecture, Process and Organization for Business Success. ACM Press, New York, 1997.

No context found.

Jacobson, I; Griss M; & Jonsson P, Software reuse: Architecture, Process and Organization for Business Success. New York, NY: Addison-Wesley, 1997.

No context found.

Jacobson, I. M. Griss and P. Jonsson Software Reuse Architecture, Process and Organization for Business Success, Addison-Wesley, 1997

No context found.

Jacobson, I., Griss, M., Jonsson, P.: Software Reuse : Architecture, Process and Organization for Business Success. Addison Wesley (1997)

No context found.

I. Jacobson, M. Griss, and P. Jonsson. Software Reuse: Architecture, Process and Organization for Business Success. Addison-Wesley, 1997.

No context found.

I. Jacobson, M. Griss, P. Jonsson. Software Reuse (Architecture, Process and Organization for Business Success). Addison-Wesley, 1997.

No context found.

I. Jacobson, M. Griss, and P. Jonsson, SOFTWARE REUSE --- Architecture, Process and Organization for Business Success,#ACM Press # Addison#Wesley, 1997#.

First 50 documents  Next 50

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC