A good Architecture?

A good system architecture exhibits conceptual integrity; that is, it comes equipped with a set of design rules that aid in reducing complexity and that can be used as guidance in detailed design and in system verification. The rules may be represented as a pattern, such as pipes and filters. In the best case there are verifiable rules, such as “any virtual device of the same type may replace any other virtual device of the same type in the event of device failure,” or “all processes contending for the same resource must have the same scheduling priority.”

A contemporary architect might say that the object or system under construction must have the following characteristics.

·         It has the functionality required by the customer.

·         It is safely buildable on the required schedule.

·         It performs adequately.

·         It is reliable.

·         It is usable and safe to use.

·         It is secure.

·         It is affordable.

·         It conforms to legal standards.

·         It will outlast its predecessors and its competitors.

 

Architecture: General abstract from this world

A building is very different from a symphony, but both have architectures. Further, all architects talk about beauty in their work and its results. A building architect might say that a building should provide an environment suitable for working or living, and that it should be beautiful to behold; a musician that the music should be playable, with a discernible theme, and that it should be beautiful to the ear; a software architect that the system should be friendly and responsive to the user, maintainable, free of critical errors, easy to install, reliable, that it should communicate in standard ways with other systems, and that it, too, should be beautiful.

 

An architecture can help assure that the system satisfies the concerns of its stakeholders, and it can help deal with the complexity of conceiving, planning, building, and maintaining the system.

 

In our discussion we will use “architecture” as a noun to denote a set of artifacts, including documentation such as blueprints and building specifications that describe the object to be built, wherein the object is viewed as a set of structures.

NSF Proposals

Here are a couple of interesting pointers for submitting an NSF proposal. This is not a comprehensive and complete list, but it does touch upon some of the important features that a proposal should contain.

1- The proposal should not be an abstract, but a self-contained description of the activity if the proposal was funded.

2- broader impacts should be described, which show the implications of advancing this research

3- Details should be understandable to people who are not in the field, but technical enough to convey the importance of the research.

CSER Conference- March 17-19

The Conference on Systems Engineering Research (CSER) is to be held at Stevens from March 17th – 19th, 2010.

 For more information, visit:

http://sse.stevens.edu/research/sponsored-conferences/cser/

 You can read the Conference brochure at: (pdf format)

http://sse.stevens.edu/fileadmin/sse/research/sponsored_conferences/CSER_2010_CFP_FINAL_.pdf

Governance vs. Management

In Governance, the weak line of control would spread horizontal, where in Management, it would be going top down.

DSM: A tool for complexity management

Research on matrix based complexity management has come a long way. Originating from a process focus with the first published formulation of a Design Structure Matrix (DSM) by Don Steward in 1981 , a whole community has developed around this research. The DSM is able to model and analyze dependencies of one single type within one single domain. For a product, e.g. the domain “components” can be regarded.

The figure shows a simple process consisting of six tasks that are shown as a flow chart on the right hand side and a DSM representing that process on the left hand side. There are numerous algorithms to analyze the overall structure of the relationships within a DSM, e.g. tearing, banding and partitioning, or the analysis for different structural properties (see DSM tutorial).

Figures: Actually the figures makes all this make sense. The website does an excellent job at making this confusing and mind-boggling as much as possible. Who in the world explains DSM in two paragraphs? lol.... he he... But that's right, because I can do it... pshhh...

Some Basics of Systems Engineering

 These are my notes from reading some books, and I find these as important concepts that should always have attention focused on them.

1- Never forget that the system being addressed by one group of engineers is the subsystem of another group and the supersystem of yet a third group. ( elevating the idea of Enterprise Systems)

2- System Engineers must identify the stakeholders needs throughout the system's lifecylce and define objects in the triad of cost, schedule, and performance ---- cheaper, faster, and better.

3- Design during the engineering of a system is the preliminary activity that has the purpose of satisfying the stakeholders requirements, and begins in the mind of the system engineer, and has to be transformed into models employing visual formats in a highly skilled manner for success to be achieved.

4- One of the legends of Systems Engineering to me could be Joe Shea, his involvement in large scale projects, definition of Systems Engineering, dedication shown by working three shifts, SE fashion icon by wearing red socks, and finally nervous breakdown for overworking himself ( duuhh!!!), but we salute him for his hard work.

5- Requirement vs Specification: Specification is a collection of requirements that completely define the constraints and performance requirements for a specific physical entity that is part of the system.

6- Design Decomposition of Architectures and Specs:
  Operational Req
  Sys Op Arch (Segment specs)
  Segment Operational Arch (element spec)
  Element Operational Architecture ( Component Specs)
  Component Operational Architecture ( CI specs)

7- Originating Requirements are found in Operational needs, or operational requirements Document, (ORD), and the restatement and derivation of the system requirements becomes System Requirement Document (SRD).