Results 1 -
2 of
2
Improving Design Intent Research for Software Maintenance
"... Design intent is a collection of decision-making factors that explain a design. Annotating software architecture models with design knowledge such as design intent may benefit maintenance activities. Unfortunately, researchers do not understand how software maintainers conduct design activities and ..."
Abstract
-
Cited by 1 (0 self)
- Add to MetaCart
Design intent is a collection of decision-making factors that explain a design. Annotating software architecture models with design knowledge such as design intent may benefit maintenance activities. Unfortunately, researchers do not understand how software maintainers conduct design activities and use design documentation. This position paper presents a summary of design activities and design knowledge, research ideas on its use in software maintenance and design intent documentation in global developments. 1. Software Architecture and Intent Software engineering relies on the expertise and judgment of designers to evaluate early designs. For this reason, understanding the intent of designers is
Switch or Struggle: Risk Assessment for Late Integration of COTS Components
"... The domain requirements of software projects often seem so specialized to developers that their original design does not incorporate any commercial-off-the-shelf (COTS) components. However, if major implementation problems are encountered at a later stage in the project, the integration of a COTS co ..."
Abstract
-
Cited by 1 (1 self)
- Add to MetaCart
The domain requirements of software projects often seem so specialized to developers that their original design does not incorporate any commercial-off-the-shelf (COTS) components. However, if major implementation problems are encountered at a later stage in the project, the integration of a COTS component that promises to solve those problems may become a desirable alternative to struggling on with the original implementation. While a number of methods and criteria have already been proposed for requirements engineering, risk assessment and candidate selection of COTS components, they were developed for application in the initial phases of a project and thus do not take into account the much tighter time and design constraints imposed in a later project stage. To spark discussion on necessary adaptations of the established methods, this position paper uses the example of a concrete project to illustrate the characteristics of “switch or struggle ” situations and proposes an initial set of risk factors to be considered at that time. 1.

