Creating product line architectures

The creation and validation of product line software architectures are inherently more complex than those of software architectures for single systems. This paper compares a process for creating and evaluating a traditional, one-of-a- kind software architecture with one for a reference software architecture. The comparison is done in the context of PuLSE-DSSA, a customizable process that integrates both product line architecture creation and evaluation

Requirement engineering evaluation of real time instant messaging using ISO 9126 metrics (integrated RMN signal reader/drafter)

Software development that does not have documentation, poses difficulties in modification and maintenance processes. Therefore, the maintenance activity system depends so much on a highly skilled software engineer. As a consequence, project management becomes imbalance especially in workload and responsibility. Moreover, clients are often unaware of the structure development of each software. Client tends to give full trust to the capability of software developer especially when there is no standard communication procedure lined out by developer. Indirectly, it causes the value of activity cost unclear to the customer. Besides, a systematic evaluation upon every system is difficult since software development structure is not concrete and abstract. The DoD-2167A standard was chosen to guide in forming standard documentation in analysis, design and testing. Unified Modeling Language (UML) technique was used to model requirement and software architecture. Object oriented programming was applied in developing the software in easing the maintenance activities. ISO 9126 quality metric is used to evaluate the software system. A signal reader system known as “Virtual Signal Reader/Drafter (VirSiRD)” system has been selected as a foundation to the software development in practicing software engineering tasks

Scenario-based design and evaluation for capability

Scenarios are frequently used within techniques for planning and designing systems. They are an especially helpful means of visualizing and understanding the incorporation of new systems within systems of systems. If used as the basis for decisions about candidate designs, then it is important that such decisions can be rationalized and quantitative assessment is particularly important. In this paper, an approach for developing complex scenarios, which incorporates the phases of systems development and deployment, is presented and a quantitative method of comparison is described. This approach is based on the development of measures of merit and measures of performance. The techniques are illustrated using cases that are relevant to Network Enabled Capability

Towards a broader view on software architecture analysis of flexibility

Software architecture analysis helps us assess the quality of a software system at an early stage. In this paper we describe a case study of software architecture analysis that we have performed to assess the flexibility of a large administrative system. Our analysis was based on scenarios, representing possible changes to the requirements of the system and its environment. Assessing the effect of these scenarios provides insight into the flexibility of the system. One of the problems is to express the effect of a scenario in such a way that it provides insight into the complexity of the necessary changes. Part of our research is directed at developing an instrument for doing just that. This instrument is applied in the analysis described in this paper

Managing conflicts among non-functional requirements

Abstractâ Non-functional requirements (NFRs) tend to interfere, conflict, and contradict with one other. Unlike functional requirements, this inevitable conflict arises as a result of inherent contradiction among various types of NFRs. A number of techniques to deal with this conflict have been developed. Majority of them focus on categorizing, documenting, or listing the potential conflicts among NFRs. Several models that represent the positive or negative relationships among NFRs have also been published in literature. However, the interpretation of NFRs may vary depending on numerous factors, such as the context of the system being developed and stakeholder involvement. Consequently, the relationships among them are not always obvious. This paper investigates the gaps in the existing research literature about the conflicts among NFRs and proposes a framework to manage this type of conflict