Talk:Systems design

Merge with Systems Development Life Cycle

Think that this article and other related articles should be combined into a coherent or a System Development Life Cycle article. Agree? --Ansell 07:18, 24 July 2005 (UTC)

Yes, and that the notion of Systems should not be confined to Computer Systems.

--Matt Whyndham March 2006

I agree, the discipline of systems should be exclusive to computing and information systems, but all general complex systems. The design priniciples that make "good" systems should be essentially universal. I agree with the above statement that this article should be merged with or at least edited to include definitions from other general systems articles.

Scotteggs (talk) 16:51, 21 April 2011 (UTC)

Missions Technology

This section stinks of self-promotion to me. It's badly done, a massive insertion by an IP user, copied from elsewhere (I believe from the strange added spaces) and mentions a person without given a reference. I have a tiny memory of some controversy over insertions elsewhere something like this. Shenme 08:24, 3 March 2007 (UTC)

Parts removed

I removed the following two parts, because they are unreadable and it is hard to understand how they are related. - Mdd 13:42, 18 September 2007 (UTC)

Processes and methods

URDAD, the Use-case/responsibility driven analysis and design method provides an algorithmic process for designing a system in a way which encourages good design principles.

Missions Technology

Computer technology has been fueled by Moore's Law. From fundamental capabilities and basic capacities the law propelled the growth of information technology. Beginning with the technology advances of integrated circuits thesetranslated to high level devices and delivery peripherals further leading to the building of stand alone systems such as ERP.

From the earliest building blocks to components, then systems and now to missions. Today the emphasis is on integrating these systems into an extended enterprise. Beyond that the next generation of product offerings will be the development delivery and execution of extended enterprise missions.

Missions integrate methods and processes that work through technology and without-technology. They form part of the overall extended enterprise but enforce a critical requirement - the development and execution of a concept or a mission that belongs to the extended enterprise and utilizes the whole to achieve the objective.

Enterprise Missions are complex entities. The complexity begins with the software and business process specifications and the architecture and design required to achieve its purpose. Additionally non-technology processes have to be integrated into the whole and is a crucial component of the mission.

Once defined the mission is built executed and its objective reached. The organizational structures that define the mission will differ from existing management and executive trees. In a war the General is now in charge. In the future the Technology & Process Builders will be in charge with the General reporting to them.

The Intraclient Waterford College of English Studies is a mission. The Rolling Stones concert tour is a mission.

Doom can be recreated as a mission. Pixar is a missions technology company. itunes and Ipod could be moulded into a missions proposition.

A mission is a large scale technological deployment of a product or space that is occupied by an enterprise and contributes a major portion of its objective to corporates revenues. It also is a major share of the net income .

Common Characteristics of Missions are

1. Architectural Complexity and Process Conceptualization
2. Concurrent processing (hardware & software)
3. Contention for shared resources (CPU, memory, channels, disk, etc)
4. Dynamic Interactions and integration between technological and manual Subsystems, methods and modes.
5. Performance dictated by channel protocols (e.g. arbitration policies, transfer modes, co-channel interference, collisions)
6. Static analysis techniques like queuing theory ignore channel contention – providing theoretical upper bound on performance (poor predictive value for architectural tradeoffs)
7. Complex Functionality
8. Validation of complex algorithms and protocols is essential
9. Quantitative and/or qualitative performance dictated by algorithmic tradeoff studies

The Solution comprises an Integrated Approach for HW and SW and the development of the - Operational Environment (mobiles, basestations, etc) using Channel Models. shared resources and concurrent processes. The architecture is built for transaction and workloads and future generation system design requirements. This is a total integration approach combining manual, emotional and technical methods and process into a single approach and managing that approach. The systems are developed with the necessary overall concepts, algorithms, protocols and controls to gain advantage over competitors and to secure and achieve the objective. To calculate progress, behavioral and performance analysis is built into the process. The design specification calls for all these as an executable specification of the various technological and non-technical components and interfaces.

Balram Shotam of Palo Alto, California invented the term Missions Technology (MST) and foresees it as the a new way for software companies to emerge within the industrial complex.

Wrong title

I consider 'Systems design' as the wrong title. Correctly, the title should be 'System design', i.e. the design of a system by means of systems theory.

--Studi321 (talk) 07:16, 18 November 2013 (UTC)

Wikipedia is built on reliable sources, see WP:RS, and not on personal opinions.

• For example the 1996 Federal Standard 1037C does mentions both the term "System analysis" and "systems analysis", acknowledging "System analysis" as synonym of "systems analysis". However it does not mention "system design" at all.

You could add the term "system design" to the introduction, if you add a reliable source stating "Systems design" and "system design" are synonym. Replacing "Systems design" by "System design" is POV, and should be undone in this stage. -- Mdd (talk) 11:53, 18 November 2013 (UTC)

• "System design" (singular) is a term of common use, when applied to the design of a specific system. However when applied to the field in general, it has always (IMHE) been described as "systems design" in the plural. Andy Dingley (talk) 21:40, 18 November 2013 (UTC)

• I understand the two candidates in the same way that Andy Dingley does. The article should remain Systems design since it covers the field in general. ~KvnG 15:11, 26 November 2013 (UTC)

 Done Thank you all. Since there is no support for these changes, the changes have been undone, see here. -- Mdd (talk) 19:47, 26 November 2013 (UTC)

Overview

I sure don't understand the following in the Overview:

Until the 1990s, systems design had a crucial and respected role in the data processing industry. In the 1990s, standardization of hardware and software resulted in the ability to build modular systems. The increasing importance of software running on generic platforms has enhanced the discipline of software engineering.

I don't understand what happened in the 1990s and I sure don't understand how standardization is relevant. I don't understand how standardization is relevant to modularity. My impression is that the preceding is something written by a relatively young person that thinks the old ways are archaic. There is no doubt that computer hardware and software has improved drastically but I see no explanation here of what has changed. There needs to be an explanation for why this claim is made but it is likely that the claim has no explanation. Sam Tomato (talk) 19:27, 9 July 2016 (UTC)

I don't understand these two sentences,

It involves a detailed design of a user and a product database structure processor and a control processor.

The H/S personal specification is developed for the proposed system.

The article would better if they were deleted. — Preceding unsigned comment added by Janekdb (talk • contribs) 12:15, 23 May 2020 (UTC)