Dec 14, 2009

Secret Signals

Well, I haven’t found the proper term to associate the secret codes that CIA folks have used; however, I would like to think of them as in terms of System. Perhaps you can come up with a way to give it a “system” name.

 

http://www.boston.com/bostonglobe/ideas/CIA_illusion?pg=3

Dec 12, 2009

Time for Publications

There comes a time during your PhD where you would have to write technical documents, and publish your work. The whole process of getting your paper published isn’t an easy one step process. As a matter of fact, its far from a 1 step process. There is so much to learn, and that was the purpose and main discussion for this class I took this semester, SYS 710: Research Methods. Not only does this class open your eyes on the process of writing a paper, but the professor encourages you to submit your work to a publication.

A couple of days ago, a great friend and mentor directed my attention to a great article that helped fixate my ideas on how to organize my paper. I’d like to share that with all you out there who are either performing research, or thinking on how to organize your paper so that it would meet the standards of a publication.




Actually, when you think you over, there are more rules and guidelines that you would need to follow to have your paper accepted. That is the guidelines for the conference/publication. In that guidline, you would have the format specified, as well as the length and the procedure on how to do the work. I’ve attached the link to the CSER paper requirements, which you can find at the bottom of the page. This will give you a pretty good idea of what is expected.


-Matin

Dec 8, 2009

System Readiness Level explained in a different context

I found this page from UK MOD Defence Acquisition website (N.American spelling is Defense), which actually does shed light on Readiness Level from a new perspective. I have never thought of combining the V-model of systems engineering to the nine levels of technology maturity.

 

I would like to reiterate that although this article explains System Readiness Level, it comes to show that this concept has not been coined as one unique tool yet. However, it is interesting to look and browse around to see what our friends in UK think about these System Engineering stuff.

 

http://aof.mod.uk/aofcontent/tactical/techman/content/srl_whatarethey.htm

Dec 2, 2009

IDEF-0 diagram

Well,

One person asked me what an IDEF-0 or A-0 diagram input and requests come from?

This question has came up time and after time, and I think it’s a good thing to break this down to the simple terms, and what better way than a diagram?

So here it is. Hope this addresses many of your questions

Nov 30, 2009

How to do a QFD

Or as its also called, The house of Quality, is a “method to transform user demands into design quality, to deploy the functions forming quality, and to deploy methods for achieving the design quality into subsystems and component parts, and ultimately to specific elements of the manufacturing process.

 

First described by Dr. Yoji Akao, who originally developed QFD in Japan in 1966.

 

Nov 24, 2009

Architecture Modeling of Cost Acquisition

One of the major problems in the engineering world out there is talking apples and apples. This simply applies to not only simple daily conversations, but cost acquisition programs, where you would have the sales team of a company work with a customer and try to break down the proposed cost. After the breakdown, and understanding of the different elements, and the inherent risk is where you realize that value of the service/product.

 

As UML 2.1 picks up in momentum, it would be a good time to look into utilizing this powerful tool to bridge this everlasting problem of misconception. I think if one can model a clear cost model for a product, then that creates a dialog medium, which will save lots of time/effort/resources and adds credibility/transparency/detail to the bidirectional conversation.

 

The only problem I see is that this methodology is easier said than done. Although I’m slowly preparing myself for all this model analysis and architecture analysis work, it is not very clear how I would go forward, even with all the software packages and modules out there. However, I do think that being in Stevens would prosper my chances of arriving at this delicious answer.

Nov 14, 2009

Enterprise Architecture : From where?

Many organisations today are establishing an Enterprise Architecture (EA) business function.
However the knowledge about enterprise architecture concepts, framework and processes within many organisations is still quite limited and at a low level of maturity.
Very often there is a good understanding of the technology and infrastructure architecture and the to a lesser extent of the application architecture but far less understanding of the enterprise architecture discipline.

 

The concept of enterprise architecture has evolved considerably from John Zachman’s original work in the 1980’s on his Framework for Information Systems Architecture.
The Zachman Framework has provided the basis for many more recent enterprise architecture frameworks and associated processes that are now available.

According to many surveys, the majority of organisations usually choose to create their own EA framework rather than adopt any existing one.
The reasons for this vary, from the requirement to support a service oriented architecture, object orientation and component based development viewpoints, to a simple desire to use a different terminology that is tailored to the language used within the organisation.

 

Nov 8, 2009

System's Engineering

Systems engineering integrates two disciplines: Engineering, the technical knowledge domain, and Systems which is an interconnected composite of people with tools and process that create a capability to meet an objective.

 

Some people think of software when I tell them about system’s engineering. Well, here is something on the line of software architecture that I found interesting a couple of days ago.

 

http://www.codingthearchitecture.com/pages/book/software-architecture-document-guidelines.html

Nov 7, 2009

INCOSE Code of Ethics

This information is retrieved from INCOSE’s website on Nov 7th,2009.

 

This Code is concerned with how certain fundamental imperatives apply to one's conduct as an engineering professional. These imperatives are expressed in a general form to emphasize that principles which apply to engineering ethics are derived from more general ethical principles.

It is understood that some words and phrases in a code of ethics are subject to varying interpretations, and that any ethical principle may conflict with other ethical principles in specific situations. Questions related to ethical conflicts can best be answered by thoughtful consideration of fundamental principles, rather than reliance on detailed regulations.

 

Preamble

Engineering is a profession that requires its practitioners to be well educated and knowledgeable. Systems Engineering, in particular, is a unique discipline in that 1) it is highly integrative, spanning elements of many activities, 2) often provides representation of stakeholders' interests other than employer or client, and 3) operates in largely international arenas where value systems, beliefs and customs vary widely. The practice of Systems Engineering can result in significant social and environmental benefits, but only if unintended and undesired effects are considered and mitigated.

 

Fundamental Principles

Systems Engineers uphold and advance the integrity, honor and dignity of the engineering profession by:

  • Being honest and impartial;
  • Maintaining the highest levels of integrity and keeping abreast of the knowledge of their disciplines;
  • Striving to increase the competence and prestige of the engineering profession; and
  • Supporting the educational institutions, the professional societies and technical societies of their disciplines.

 

Fundamental Duties to Society and Public Infrastructure

  • Guard the public interest and protect the environment, safety and welfare of those affected by engineering activities and technological artifacts.
  • Accept responsibility for your actions and engineering results, including being open to ethical scrutiny and assessment.
  • Proactively mitigate unsafe practice.
  • Manage risk using knowledge granted by a whole system viewpoint and understanding of systemic interfaces.
  • Promote the understanding, implementation, and acceptance of prudent Systems Engineering measures .

 

Rules of Practice

  • Act legally, honorably, honestly, justly, and responsibly.
  • Respect, protect, and preserve the intellectual properties of others.
  • Honor all legal contracts and agreements.
  • Treat all constituents fairly.
  • Give prudent advice. Be truthful, objective, and maintain your professional and technical integrity.
  • Provide diligent and competent services to the best of your ability.
  • Respect the trust and the privileges granted to you.
  • Avoid conflicts of interest and the appearance thereof.

 

 

Nov 5, 2009

SysML seminar at Stevens

INCOSE will host the main guy who has been SysML. This lecture which is hostel by INCOSE will have a day seminar on SysML which is something that Stevens currently lacks. I am going to attend this seminar, and find out more detail about it. It should be around NOV 20th.

 

For the exact date, contact me: hellomatin@gmail.com

Nov 4, 2009

Basics: Sequence Diagram

Undoubtedly useful, but what does it look like?

http://www.tracemodeler.com/articles/a_quick_introduction_to_uml_sequence_diagrams/images/a%20typical%20sequence%20diagram.png

An excellent guide to SysML

Read the Incose 2008 OMGSysML tutorial that is published in PDF format.

Not only does this explain SysML in the simplest terms, it is probably one of

The best sources to learn SysML thoroughly.

 

You can obtain a copy of this document at this website ( if it’s still hosted when you visit the site of course)

http://www.sysmlforum.com/training.htm

 

Enjoy.

Nov 2, 2009

Systomics: Where to look for failures

http://systomicslab.com/

 

Systomics is the foundational science of systems thinking. It asks and seeks to answer these two key questions: ‘What is a system (in the abstract)?’, and, ‘What is the meaning of this (particular) system?’ Systems thinking is itself an applied science asking ‘How can the notion of system be used to make sense of or to improve reality?’ Applied systems thinking benefits a wide range of domains and thereby provides testimony and future insights for systomics. 

At Stevens Institute of Technology within the School of Systems and Enterprises (SSE), the Systomics Laboratory has been established to study the science of systems thinking so we may look at systems over space and time and may find the true systemic remedies to systemic failures.

 

Nov 1, 2009

Oct 30, 2009

Modeling an enterprise

Many reasons why, 1) to preserve knowledge 2) identify teams that help the
enterprise achieve it's goals 3) compliance requirements 4) dates and more

Oct 28, 2009

Vensim: a soft system Diagram





Ventana Systems, Inc. provides products and services to solve hard problems and improve organizational performance. Ventana publishes Vensim which is used for constructing models of business, scientific, environmental, and social systems.

This is an excellent tool that I learned for my Systems 710 class. It's in some way a brainstorming tool that would eventually organize your thoughts. It also links individual states to each other, to show a positive or negative association to one another.

I'm planning to use this to depict the obstacles to earning my PhD at Stevens with this tool. I'm sure the outcome will be beneficial, one way or another.

Heterogeneity

Heterogeneous is an adjective used to describe an object or system consisting of multiple items having a large number of structural variations. It is the opposite of homogeneous, which means that an object or system consists of multiple identical items.

In the world of enterprise computing, heterogeneous data is a mix of data from two or more sources, often of two or more formats, e.g., SQL and XML. Distributed systems are called heterogeneous if they contain many different types of hardware and software. heterogeneity of the system means the ability of that system to work with different systems

 

A champion in Systems Engineering

Lecturers and Instructors have the important responcibility of educating others. There are poeple who do the work, and there are others who DO IT RIGHT. Eirik Hole, a lecturer at Stevens Inst of Technology, is a well spoken and detail oriented individual with a sharp eye for Systems.

He has the knowledge and capability to instruct a diverse class, and brings excitement and enthusiasm to the class environment. Given the criticality of Systems Engineering in the next decade, it is vital to keep up with todays current events, and prepare for a System Oriented mindset of tomorrow.

Oct 27, 2009

Money/Payscale's Best Jobs Survey


From CNN Money:
#1 Job: Systems Engineering!!!!!!
What they do: They're the "big think" managers on large, complex projects, from major transportation networks to military defense programs. They figure out the technical specifications required and coordinate the efforts of lower-level engineers working on specific aspects of the project.

Why it's great: Demand is soaring for systems engineers, as what was once a niche job in the aerospace and defense industries becomes commonplace among a diverse and expanding universe of employers, from medical device makers to corporations like Xerox and BMW.

Pay can easily hit six figures for top performers, and there's ample opportunity for advancement. But many systems engineers say they most enjoy the creative aspects of the job and seeing projects come to life. "The transit system I work on really makes a tangible difference to people," says Anne O'Neil, chief systems engineer for the New York City Transit Authority.

http://money.cnn.com/magazines/moneymag/bestjobs/2009/snapshots/1.html

Oct 26, 2009

Systems thinking and keywords in the area

According to managementhelp.org, systems thinking is a way of helping a person to view systems from a broad perspective that includes seeing overall structures, patterns and cycles in systems, rather than seeing only specific events in the system. This broad view can help you to quickly identify the real causes of issues in organizations and know just where to work to address them. Systems thinking has produced a variety of principles and tools for analyzing and changing systems.

By focusing on the entire system, consultants can attempt to identify solutions that address as many problems as possible in the system. The positive effect of those solutions leverages improvement throughout the system. Thus, they are called “leverage points” in the system. This priority on the entire system and its leverage points is called whole systems thinking.

Also look at :http://www.pegasuscom.com/systems-thinking.html

Keywords: Links, Scopes, Principles of Change,Causal Loop Diagrams, Systems Diagrams, Five Disciplines of Systems Thinking,Chaos Theory

History of Use Cases

A use case in software engineering and systems engineering is a description of a system’s behavior as it responds to a request that originates from outside of that system. In other words, a use case describes "who" can do "what" with the system in question. The use case technique is used to capture a system's behavioral requirements by detailing scenario-driven threads through the functional requirements.

In 1986, Ivar Jacobson, later an important contributor to both the Unified Modeling Language (UML) and the Rational Unified Process (RUP), first formulated the visual modeling technique for specifying use cases. Originally he used the terms usage scenarios and usage case, but found that neither of these terms sounded natural in English, and eventually he settled on the term use case. During the 1990s use cases became one of the most common practices for capturing functional requirements. This is especially the case within the object-oriented community where they originated, but their applicability is not restricted to object-oriented systems, because use cases are not object-oriented in nature.

Oct 20, 2009

Project Management: Solar Tower



An example of excellent project Management in my opinion. I will post more about this in the near future, as I am doing an extensive case study on the Seville Solar Power. This is an awesome project that deserves way more attention as it has been getting. So I'm going to contribute to the body of works that has been published out there.

Oct 19, 2009

A great Systems Software

Hello and Welcome

Hello,
Thank you for checking out this blog. It is my intent to share interesting discussions that relate to the world of Systems.

Please bookmark and check these pages often.

Yours,
Matin Sarfaraz