Systems+Engineering+Sources

=Systems Engineering=

**Based on the following external sources:**

 * Maggie Castle**
 * [[file:Systems Engineering Documentation .doc]]

AP, Sage. and JE, Armstrong. (2000). Sample Outline for Systems Engineering Documentation. clarusinitiative.org. retrieved from google scholar

This source is a sample outline for documenting systems engineering. It includes topics such as the technical plan, the concept of operations, requirements definition, design, implementation, and references. I thought this source was interesting for this project because I imagine that in the future we will need to write a document all about this product we are creating and this outline could help us in figuring out what to include in our systems engineering process. This outline displayed to me  that systems engineering includes everyth ing from thinking of the concept of the project, to planning, designing, evaluating, and sharing the final product. Basically it is each step that goes into the process of engineering a product that includes many parts. It also includes how these projects are carried out and managed. This reference is how you would document your experiences with system engineering.


 * [[file:Systems Engineering Documentation .doc]]

Kotonya, G. (1998). Requirements Engineering. Retrieved from computing.dcu.ie from google scholar. This source is set up in a slide show format about Requirements Engineering but a portion of it discusses the systems engineering process. The Systems Engineering Process goes as follows:


 * 1) Systems Requirements Engineering -this is when the requirements for the system as a whole are developed and written to be understandable to many
 * 2) Architectural Design - when the system is broken down into sub-systems
 * 3) Requirements Partitioning - when requirements are assigned to these sub-systems
 * 4) Software requirements engineering -when the systems requirements are made for the software
 * 5) sub-system development - the sub-systems are designed and implemented
 * 6) system integration - the sub-systems are put together
 * 7) system validation - the system is tested against the requirements

This series of steps are ones that could be very well incorporated into our project and have already have begun to be.


 * Dan Goldberg**

Tables of processes
 * [[file:Re-evaluating Systems Engineering Concepts using systems thinking.pdf]]

Re-evaluating Systems Engineering Concepts Using Systems Thinking

These authors define systems engineering as “making things work better”. A systems engineering process they talk about has the acronym SIMILAR: State the problem, Investigate alternatives, model the system, integrate, launch the system, access performance, and re-evaluate. This is basically like the previous article with a few extra steps thrown in. They also stated multiple other processes used for specific fields and compared their “SIMILAR” process. They did this to show that the SIMILAR process can be used across many fields of study. The writers say it is generic because it has few, broad steps. Also, they write that some steps could be skipped, omitted, or modified, but no new functions are usually added
 * [[file:Applying Systems Engineering Principles in Improving Health Care Delivery.pdf]]

This article uses the systems engineering process towards healthcare. They start by defining a system as many “entities” working together as a “global system” (432). Systems change states when an event occurs. From this sequence of events, a “state trace” is formed. Next, the author writes about how the systems engineering process aids healthcare in six fundamental steps.


 * 1) Think about a purpose/goal and “performance thresholds”
 * 2) Obtain data
 * 3) Make a model
 * 4) Study the model to learn about the behavior more
 * 5) Use what you have observed in the model to enhance/optimize your system
 * 6) Develop and carry out plans

I noticed that this list would be a good checklist for our project. The authors then go on down the steps with their healthcare application. They identify that they are looking at the hospital resources, patients and staff. Next they obtain data by looking at HL7 messaging. These messages are generated for each patient whenever something needs to be done to them. Then they made different models showing different HL7 messages over time with 2 different patients. Next they are refining their models to enhance the healthcare system and [|can you learn to sing].


 * Sam Valerio**

This article, from Google Scholar, tells how to apply Systems Engineering to the Project Cycle. It makes a simple diagram for the project cycle, one that I do not fully understand, but from what I gathered, it is simply a "Vee" (shape, V) that goes from upper left to upper right. It lists a series of processes in two sections: the left side of the Vee, Decomposition and Definition, or the steps that make up the research and work breakdown/requirements, and the right side, Integration and Verification, which include the steps of creating the final product and verifying that it meets creator requirements and more importantly user needs. Here is the Vee diagram in the article:
 * [[file:SE &Project Cycle, Forsberg&Mooz, 1995.pdf]]

(It is difficult to read but it was the best image available) This method of organization is basically what we have already planned to do. So far we have defined requirements, systems engineering, work breakdown structure, and developed contacts for potential users of our device. Once we determine which users we will create it for, we will start with step one, which is "understand user requirements, develop system concept(which is what we think it should look like and how it will function) and validation plan." Following these steps, we will complete our task for the people who want our device.
 * []

The source of this article, New Product Development Solutions, is a company that does exactly what its name says: they provide guidance for the output of any product. This database defines systems engineering as a process based on a hierarchy of system requirements. This means that priorities need to be set in the planning for designing any type of technology. The process also emphasizes making alternative solutions to problems, and weighing each one, finding out what would be the result, and ultimately using the best one possible. The hierarchy is consisted of subsystem levels, the first level being Functional Analysis, Allocation, and Synthesis. During functional analysis, performance requirements are used to identify system functions/subfunctions in order to find alternatives to meeting system requirements. Also, if necessary, a timeline analysis may be developed for the process. In the allocation process, systems engineering decides what performance requirements belong in what part of the development process. This way, the developers can decide what type of resource is needed for each function and subfunction, such as hardware, software, or personnel. During the synthesis portion of the process, engineering specialties are used to make a system architecture design, which is basically a layout of the future final project. Finally, it is imperative that the process be controlled and supervised very closely to make sure nothing goes wrong in any phase of the process. In making our PTM device, this process has to be followed. This will ensure that we are making priorities in any steps we take to create our system. When all of these priorities come together, the final project will be completed in an orderly manner. This system will also help determine who does what when we specialize at the end of the first quarter.

This source is used by the Department of Defense as an introduction to systems engineering. Systems engineering is a form of project management. It provides an organizational and design technique for all processes involved in completing a project. The source provides multiple styles of systems management, both explained through text and displayed through flowcharts and graphs. From beginning to end, systems engineering sets a path for how to move on to the next step without actually deciding what to do. During our task to design a PTM, we will use systems engineering to keep our processes organized. Once we've completed a step, we will always know what needs to be decided or reviewed next if we incorporate systems engineering. This sources addresses the ideas that systems engineering works best when applied with minimum risk at hand. When too much risk is involved, it makes the process much more difficult to carry out. Systems engineering allows all different types of engineering to come together and contribute what they can to the process of design. This source implies that systems engineering does, in fact, provide decision making opportunities, while requirements engineering does not. The author is obvious with his bias as a requirements engineer. The tables and charts provided in this article are helpful in that they allow a visual of how many different types of people, specifically engineers, are involved in a design process. From this source, we would infer that we should not use systems engineering as a technique because of how new and risky our project is.
 * Nadya Spice**
 * [[file:10 systems eng fundamentals pdf.pdf]]
 * Systems Engineering: A Requirements Engineer's Viewpoint


 * Kevin Dickey**
 * [[file:Model-Driven Systems Development.pdf]]
 * [[file:Software System Engineering- A Tutorial.pdf]]

L Balmelli, D Brown, M Cantor, and M Mott. "Model-driven systems development. " //IBM Systems Journal// 45.3 (2006): 569-582. ABI/INFORM Global, ProQuest. Web. 19 Sep. 2010.

This article argues that traditional systems engineering processes are not effective, as they merely create what the author calls “point solutions” – solutions for a specific, unchanging set of requirements. Such solutions are slow to react to dynamic environments and conditions, as well as being costly to reorganize and improve. The author instead describes a “model-driven” systems engineering concept. Traditional systems engineering processes create products that often lack adaptability in the market, as they were designed around a single set of parameters. While the concept of having a set of parameters for a product to meet may simplify the communications process between different disciplines, it often hampers the adaptability of the end product and also increases the cost of maintaining the product over its life cycle. In order to achieve more effective systems engineering processes, tighter collaboration is necessary between the various disciplines involved in a project. This allows for a less definite set of parameters, creating additional adaptability for a product and allowing it to stand out within its market. Model-driven systems design requires many different groups who are assigned the task of reviewing certain components and small systems within the larger system. The entire system specifications are designed beforehand, and it is the task of these groups to make these specifications a reality. These groups are all directly linked to each other, creating a stronger basis for collaboration between different parts of the system. This type of systems engineering, the author argues, is more cost-effective and produces better results than traditional systems engineering.

Thayer, Richard H. "Software System Engineering: A Tutorial." //Computer// 35.4 (2002): 68. //Academic Search Elite//. EBSCO. Web. 19 Sept. 2010.

This article provides a useful overview of systems engineering, particularly in the area of software development. Thayer notes at the beginning of the article that many software systems do not meet their projected schedules or budgets, something which cannot be remedied merely by keeping a close eye on the technical status of the project (such as the number of tests successfully completed, how many resources are used, etc). Instead, both technical status and products must be monitored in order to get a sense of a project’s completion and [|can you learn to sing]. “A system,” writes Thayer, “is a collection of elements related in a way that allows a common objective to be accomplished.” This includes “hardware, software, people, facilities, and processes.” System engineering combines engineering, science, and managerial skills to create a product that serves a specified purpose, serving a need of a consumer. The process of system engineering involves five main functions, the first of which is “problem definition”. This essentially asks, “What does the consumer need? What are the constraints that I have on a product to fill this need?” Next is “solution analysis”, which provides a real-world solution for the need of the consumer, based on the constraints that were determined during the problem definition phase. Third is “process planning.” This step determines what tasks need to be done by which groups of people, the amount of resources needed for development, and any potential risks to the project. Next is “process control”, which is the act of overseeing the project as it is under development. The final step is “product evaluation”. This step is a comprehensive test and evaluation of the final product that is created by a project.

Within the realm of software engineering, the process of project management involves the assessment of a software’s particular costs and risks, creating deadlines, integrating the various disciplines involved with the software, and also testing the software on a regular basis to establish that it meets goals for cost-effectiveness and technical requirements. It is crucial that these aspects of the system engineering process are not neglected; otherwise, the system may not function properly or integrate particularly well with other systems.