{"title":"Striving for coherency to mitigate the complexity of system design","authors":"D. Mulcare","doi":"10.1109/ECBS.1997.581899","DOIUrl":null,"url":null,"abstract":"Software system complexity needs to be viewed from the perspectives of both the design product and the design process. In typical practice, design products appear quite overly complex relative to the capabilities provided. Frequently, system designs seem to exhibit a large degree of unwarranted complexity. On the other hand, system-level design methods are usually lacking in complexity relative to the challenge of essential design tasks. In consequence, too many design commitments are made without adequate bases, out of proper order, or by default. The result of such design commitments is a combination of unwarranted complexity and compromised system capabilities. Two other distinctions that also need to be acknowledged are the differences between: functional architecture and architectural design; and system requirements and system specifications. Distinctions are usually not observed in development processes that are dismissive of the nature and ramifications of proper system-level design. Here, the dilution of the system design effort tends to compromise the design product, because many of the major design commitments are made in the absence of a precisely defined architectural design. Whether soundly based or not, these early-on commitments continue to profoundly affect product construction and complexity throughout development. Accordingly, it is vital to invest in rigorous system-level design methods and practices. They can engender coherence, and hence mitigate complexity in design products and disorder in later stages of development.","PeriodicalId":240356,"journal":{"name":"Proceedings International Conference and Workshop on Engineering of Computer-Based Systems","volume":"7 1","pages":"0"},"PeriodicalIF":0.0000,"publicationDate":"1997-03-24","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"4","resultStr":null,"platform":"Semanticscholar","paperid":null,"PeriodicalName":"Proceedings International Conference and Workshop on Engineering of Computer-Based Systems","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1109/ECBS.1997.581899","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
引用次数: 4
Abstract
Software system complexity needs to be viewed from the perspectives of both the design product and the design process. In typical practice, design products appear quite overly complex relative to the capabilities provided. Frequently, system designs seem to exhibit a large degree of unwarranted complexity. On the other hand, system-level design methods are usually lacking in complexity relative to the challenge of essential design tasks. In consequence, too many design commitments are made without adequate bases, out of proper order, or by default. The result of such design commitments is a combination of unwarranted complexity and compromised system capabilities. Two other distinctions that also need to be acknowledged are the differences between: functional architecture and architectural design; and system requirements and system specifications. Distinctions are usually not observed in development processes that are dismissive of the nature and ramifications of proper system-level design. Here, the dilution of the system design effort tends to compromise the design product, because many of the major design commitments are made in the absence of a precisely defined architectural design. Whether soundly based or not, these early-on commitments continue to profoundly affect product construction and complexity throughout development. Accordingly, it is vital to invest in rigorous system-level design methods and practices. They can engender coherence, and hence mitigate complexity in design products and disorder in later stages of development.