| 作者 |
 庵拚“博导“的巨献：献给“狼多肉少”的鬼谷中国工程师 ZT (超长但有用) |
 |
功夫王
[博客]
[个人文集]
头衔: 海归中将
声望: 专家
性别: 
加入时间: 2004/02/21
文章: 6733
来自: 美国，加拿大，中国
海归分: 531677
|
|
|
作者：功夫王 在 海归酒吧 发贴, 来自【海归网】 http://www.haiguinet.com
A Systems Engineering Approach to Dating and Relationships
written by Larry Kahn
In the fall of 1995, I was taking a class in systems engineering management, and we had to write a term paper analyzing a current project we were involved in. It could be any type of project, from work related to building a house. So I decided to base my paper on my real life experiences with dating and finding my eventual spouse. I really did follow this approach!
One of my basic philosophies is yes, you do have to pay attention to your partner, but if a relationship is real "work", then you probably picked the wrong partner in the first place. You won't have this problem if you follow good systems engineering practice. Do most of your analysis up front, and make sure of your requirements before design and production. It's always easier (and CHEAPER, hint, hint - divorce) to correct the program bugs before you release the product than to keep sending out "fixes" after it's in the field.
In case you're wondering what my background/experience is in all this, well, for the past 20-25 years I've basically done two things - be an engineer and chase women. Over the years, I estimate I met anywhere from 750 to 1000 women for dates (most of these were the "one time meeting" often based on personal ads), plus get involved in about a dozen long term relationships (almost all of them very positive experiences), until I finally found Cathy. There were relationships based on being best friends, relationships based on pure physical lust (who cares if she can hold a conversation), a few lucky ones based on both, and even a couple of email/long distance relationships. So I figure I've about seen and done it all by now.
________________________________________
Systems Engineering and Life:
Designing, Developing, and Maintaining a Permanent Relationship
December 1995
Introduction
"Systems engineering is defined as the set of concepts and techniques which are necessary to proceed from the original system concept to the creation of the system or, more completely, to the satisfaction of the original need."(1) This paper will present a systems engineering management approach to an unlikely (from an engineering point of view) problem - my real life process of finding and then maintaining a primary, lifetime partnership (traditionally defined by a marriage).
In a very broad sense, this process is somewhat analogous to an evolutionary systems design and acquisition in which the most suitable commercial off-the-shelf (COTS) product (human female) must be selected to integrate into the final functioning system (marriage). COTS, as defined by the Federal Acquisition Regulation, is "an item produced and placed in stock by a contractor, or stocked by a distributor, before receiving orders or contracts for its sale."(2) On the spectrum of fully COTS to fully developmental, a person clearly falls closer to the COTS end. While you can encourage some change, for the most part, what you see is what you get.
The actual process of meeting new people and finding a partner is not necessarily a smooth one in terms of a well managed project. Seemingly good solutions can suddenly turn bad for unexpected or even unapparent reasons. There is no single project manager "in charge," and traditional configuration management of the components is virtually impossible since much of what the other person is or does is out of your control. However, there are definite parallels between the real life steps and standard systems engineering management practices, as shown in the following table:
Real Life Step System Engineering Equivalent
Deciding you want a permanent partner Need statement
Defining what you want in a partner and a relationship Requirements analysis and specification
Conceptual design
Risk management plan
Determining methods for meeting potential mates Evaluation of alternatives
Cost and schedule management
Dating different candidate people Preliminary design and prototyping
Tradeoff studies
Modification of requirements/process via feedback loop
Determining you have found a possible partner Tradeoffs
Multi-criteria analysis evaluation
Detailed design, test, and evaluation
Getting engaged (or equivalent) Refinement of system operational specifications
Final acceptance testing
Getting married System deployment
Continuous operational testing
Staying employed, saving money, etc. System maintenance and support
Measures of effectiveness
Resolving differences System assessment
Modification planning and change implementation
Divorce or one person dies Planning for expected or premature system retirement
One important point needs to be made with respect to the specific relationship Cathy (my significant other) and I have forged. It is very nontraditional and unconventional as compared to society's "norm;" this is reflected in those analyses and discussions pertaining to our relationship. For instance, there was no formal "engagement," we will not wear rings or change names, and the wedding itself is simply viewed as a big party for friends and family. Many of the typical "stages" of a relationship progressing to marriage have either been blended together, reordered, or simply ignored.
Since I view this relationship so positively, there is the distinct possibility of my personal bias influencing the presentation and conclusions. I have attempted to present the subject matter as objectively as possible, either by including other people's observations and feedback, or by including measurable data if available.
Background
In the spring of 1991, a woman I viewed as a possible permanent partner ended our relationship. During the following several months I spent a lot of time thinking about that relationship and other past failed relationships in an effort to determine what had gone wrong. I also tried to gain a better understanding of myself, and my needs. Of course, I had done a lot of these things previously, but this time I seemed a little more focused and organized about it. According to Sage(3), there are at least four management perspectives - inactive, reactive, interactive, and proactive. The basic progression from inactive to proactive deals with how quickly problems are recognized and dealt with. Previously, I had taken a more reactive and interactive approach, in which problems are dealt with either after or as soon as they arise. I made the effort to incorporate the proactive perspective, in which the attempt is made to predict the potential for trouble and to plan for its minimization.
Over the next few years of dating (with several somewhat long term, though not permanent relationships), I realized that I was at least being more successful at finding quality women (based on my requirements list outlined in the next section). Eventually I was fortunate enough to meet Cathy in the summer of 1994, and at this point (fall 1995) we are well on our way to making our relationship permanent.
Looking back on the process to date, I find that I had unknowingly been applying many of the traditional systems engineering steps along the way. Perhaps that has contributed to the success, so far, of the process.
Needs and Desires
"The system engineering process generally commences with the identification of a 'want' or 'desire' for one or more items, and is based on a real (or perceived) deficiency."(4) For me, defining the need was easy, I've always had the desire to be involved in a good relationship, and I very much wanted to find someone permanent with whom I could share a future.
There were various long term risks that could be identified. The biggest risk was making the assumption that I would eventually find someone permanent. I have been careful to not base certain life decisions on that assumption. For instance, I could have put off buying a house until it was with my eventual partner. However, financially it was advantageous to do that on my own as soon as I was able and I have done so (twice). Another risk I could identify was eventually becoming frustrated about not finding someone and then "settling" for a flawed relationship. This is a definite risk and I've seen its consequences many times in real life. To minimize it I formulated a set of requirements for the person I would like to end up with and the relationship parameters that were important to me, and planned to use this list as an evaluation tool. I also had decided long ago that given the choice of being single or being in an imperfect relationship, I would rather be single.
Picking out the proper partner is not easy. Almost half the marriages in the United States end in divorce.(5) "Are people really so dumb that they pick wrong most of the time? Probably not, what they're doing is picking on the basis of what matters to them in the short run. But what matters in the long run may be different. The factors that count change, people change, relationships change."(6) Therefore, it is important to establish the true requirements, and also a plan for managing their change.
Defining what I wanted in a partner and how I wanted us to function in a relationship was the equivalent of performing a requirements analysis and then defining a specification for both the other person and the system in which the two of us would function. Much of my analysis was based on prior dating experiences; in twenty years one can collect a lot of data. I was able to find several good books on the subject of relationships (Sills(7, and DeAngelis(9)) to help me organize the data and formulate my requirements. I think I gravitated to books with a well thought out, somewhat analytic approach. Indeed, many of the recommended procedures were ones that in a way I was already using.
A detailed list of all my requirements would be too lengthy to list here, but I have included the ones I feel were most important (in no particular rank order):
Partner Requirements Relationship Requirements
Intelligent Similar Goals
Attractive Frequent and open communication
Affectionate Willing to put time into the relationship
Good sense of humor Partners viewed and treated as equals
Similar values to my own Most decisions made mutually
Financially secure Balance of together and alone time
No children or desire for any Partners abilities complement one another
Dependable, someone I can trust
My conceptual design of the ideal partnership was one where the two people were best friends as well as being wildly passionate about each other, a partnership where both people had similar goals and lifestyles, whose strengths and weaknesses complemented each other, and who just plain "liked" being around each other. Rechtin sums up the partnership concept rather nicely in system terms: "1. A system is a complex set of dissimilar elements or parts so connected as to form an organic whole. 2. The whole is greater in some sense than the sum of the parts, that is, the system has properties beyond those of the parts. Indeed, the purpose of building systems is to gain those properties."(10)
Methods for Meeting People
There are many different ways for meeting women; each has its own distinct advantages and disadvantages. In making this analysis of alternatives, I had unknowingly used what amounted to a variation of the Pugh Concept Matrix(11) to make a decision. In this method, each alternative is assigned a value relative to a norm, and the alternative with the most positive values is chosen. If possible, positive attributes from non-chosen alternatives are then incorporated into the process. For my problem, I assigned the values low, medium, or high for each alternative depending on how well it satisfied the selection criteria.
Criteria Low cost Feeling of taking an active role High number of people to choose from Able to specify my requirements Good previous experience Efficient use of my free time
Alternative
Do nothing, try and meet people in daily life high low medium low low low
Join a social or activity group medium medium medium medium low medium
Use a dating service low high low high low medium
Place a personal ad medium high medium high high high
Answer personal ads high high low medium high high
Ask friends to set me up high medium low high low high
Go to dances or clubs medium medium medium low low low
What I ended up doing in reality was to rely almost exclusively on some variation of personal ad, either locally or on the internet. The assigned values in the Pugh Concept Matrix confirm that using this approach was my preferred alternative.
There was also an issue of cost and schedule management to this process. Cost for me was defined more in time commitment rather than in a dollar amount. I had a very good idea of approximately how long I was willing to invest in each phase of the process, and set various milestones. I was willing to initially see a person 3 or 4 times to decide whether or not we even wanted to start dating semi-seriously. I expected it to become exclusive within a month, and in no more than 3 months both people should agree that there is a real possibility that things could be permanent. At 6 months I expected the decision to be made that yes, we think this will be permanent, and to start taking definite steps in that direction. My opinion is that by the time you reach your 30's, if you can't decide in 6 months, then you should stop wasting the other person's time and try someone else.
This schedule may appear to be rather rigid and inflexible. Was I prepared to make a change to it (configuration management) if necessary? The short answer was no, other than perhaps to alter the schedule by a few weeks if necessary. I take a very direct and straightforward approach to life, and this schedule was an accurate reflection of who I am, what approach works best for me, and some of the personality traits/styles of my desired partner. I was willing to take the risk of applying these schedule constraints to my search, and possibly ruling someone out prematurely.
Dating
One aspect of evolutionary systems design is that of constantly refining and modifying the requirements based on feedback from using the system in its present state of development. As Beam states, "Since the system may be substantially different in initial and later phases of evolution, the requirements placed on it in the earliest implementation may be modest and easily obtainable. As it grows in function and scope, feasibility considerations that were of no concern in the initial phase may become serious barriers to further evolution."(12) This concept is particularly relevant here, since the expectations and goals at the very beginning of a dating relationship are likely to be fewer and easier to obtain than those of a more established relationship that is progressing toward marriage.
For my process, the phase of dating different candidate people was the systems engineering equivalent of preliminary design and prototyping. This particular process presents an interesting situation not typically desirable, but impossible to avoid. Each subsequent prototype does not necessarily represent an improvement over the previous version with respect to the final requirements. In many ways dating is a trial and error process and at any given time the prototype in use may turn out to be the final design.
A major systems engineering task performed while in the dating phase were tradeoff studies to refine the system requirements. What I had to do was to determine which qualities or traits I absolutely required, and which I was willing to compromise on. As stated before, people are like COTS products, the aim is to find the best fit from the available choices. As Sills succinctly puts it, "Life is a blueplate special. You want the chicken, it comes with the peas. You want the roast beef, you get Brussels sprouts. NO SUBSTITUTIONS."(13)
I met and dated numerous women over a period of a few years, some for extended periods of time. In the process, I discovered several new things about myself and as a result had to go back and refine or add to my initial requirements. I also became more certain as to which qualities I might be willing to trade off for others (and conversely, which I wouldn't).
For example, I met one person who satisfied quite a number of my requirements and had the added benefit of a substantial inheritance at some future time. Another person was again a close fit except for a lack of time and energy commitment to the relationship. With a third person, I attempted a long distance relationship that ultimately failed; from that experience I learned that I was simply not cut out for that type of thing and limited my searching to the local area. These experiences, along with meeting many other women, helped my to prioritize my requirements and make easier the task of determining tradeoffs.
One thing I was able to do was to adhere to my schedule planning. Even though it was difficult at the time, I took the responsibility to end the two relationships that had seemed the most promising. At an earlier age I probably would have let them continue for an indefinite period, since for the most part they were good relationships. But they were unlikely to ever progress to permanence given my requirements, and I could not afford the time cost if I wanted to maximize my possibility of achieving my goals.
In June 1994, I placed an ad in Washingtonian Magazine. This was definitely not the first time I had done this, although this ad perhaps described me the best, and was probably my most specific one in terms of constraints and requirements. It read, "Enthusiastic, eclectic engineer. 40, athletic, irreverent, dependable, affectionate SWM seeks fit, witty nonsmoking SWF unswayed by typical Washington yuppiness. Happiness is marrying your best friend and sharing a spontaneous, childfree, lifelong romance. Failing that, free chocolate."(14)
I received approximately 25 responses from the ad, one of them from Cathy. One of the biggest plusses about our relationship was that there was full communication right from the start. We could then, and still do, talk about anything and everything. To this day, our friends are amazed at how much we say to each other and how direct our discussions are. None of them really seems to understand our style, although they all say we are perfect for each other. This is one of the most important requirements for relationships as well as for well managed system engineering projects, it is critical to have effective communication among all the participants.
It became clear to me fairly early on that this relationship had a real chance to go somewhere. Fortunately, we each independently had very similar schedules, we both agreed that approximately six months was long enough to make a decision about permanence, if we got that far.
The stage of the relationship at this point was one of design refinement and multi-criteria analysis. The biggest potential for failure appeared to be Cathy's hesitancy to make a final decision on permanence, based on various past experiences. As part of a design analysis (and to objectively show her the final design was good), I had us both make compatibility lists as described by DeAngelis.(15) I was virtually certain that the results would verify that each of us was satisfying the other's partner requirements list while our overall relationship expectations (system operational requirements) were similar.
The compatibility list breaks down the requirements into ten general areas, and uses a method to assign a compatibility factor for each area, and an overall score. The ten areas are:
1. Physical Style - appearance, eating habits, fitness habits, hygiene.
2. Emotional Style - romance and affection, how partner treats you, expression of feelings.
3. Social Style - personality traits, interaction with others.
4. Intellectual Style - educational background, attitude toward learning and culture, creativity
5. Sexual Style - attitude, skill, ability to enjoy
6. Communication Style - how, attitude, other forms of expression
7. Professional/Financial Style - money management, attitude toward success, work habits
8. Personal Growth Style - self improvement, ability to change, willingness to work on relationship
9. Spiritual Style - morals, philosophy of life, religious practices
10. Interests and Hobbies
Fortunately (for me), the results confirmed my beliefs. We each rated the other as between 90% and 95% compatible, which is an exceptionally high score. The lowest category for each of us was physical style, not unexpected because we knew that each of us was not the other's physical ideal. However, we had already discussed this early on and it was clear that each of us was willing to trade off a less than ideal physical partner for other traits that were of greater importance. The basic requirement was met, although the ideal objective was not. This often occurs when incorporating the results of tradeoff analyses into the design.
Other detailed design, tests and evaluations were being performed during this time. We spent a lot of time at each other's places sharing everyday activities, things a couple would be doing at least 75% of the time. One test that was important for Cathy (but not for me) was to meet each other's parents. We did this about five months into the relationship, on nearly successive weekends we flew to Miami to meet mine; then hers happened to be here in DC on other business. The Miami trip, in particular, was about as stressful as anything I can imagine (for a variety of reasons), but looking back, it showed how well the system could function under harsh conditions.
From a systems engineering perspective, there was no formal test plan, nor any attempt to test each individual requirement. Most of the requirements were not "testable" in the usual sense; success or failure was a subjective determination by each partner and could not be quantitatively measured.
Preparing for Permanence
Toward the end of 1994, Cathy and I made the mutual agreement to make things permanent. At that point, our partnership system entered the stage of refinement of the system operational specifications, along with final acceptance testing. Final acceptance testing is normally performed before the system is deployed in the field; in our case the distinction between final acceptance and operational testing is somewhat blurred since we have already bought a house together. We plan on a May 1996 wedding, which will be the equivalent of system deployment.
During our final acceptance phase we have essentially been operating the system under real world conditions. While we had mutually established a set of ideal operational requirements before moving in together, now that we are actually living with each other we are getting an idea of how things will work firsthand. Instead of each person being 100% responsible for their own house and associated upkeep, we now have to share and allocate those responsibilities. In addition, differences in living styles and schedules must be addressed.
A prime example of an operational requirement that would have been difficult to verify and test up until this point is the allocation of cleaning chores, and what the standards will be. I'm much more tolerant of messiness than she is. We have had to compromise on the cleanliness standards for common spaces, while rooms that belong to an individual (like her study or my downstairs recreation room) are primarily the responsibility of that person.
Our biggest difference (we have known about this since the beginning) is that biologically we are total opposites. Cathy is a morning person and gets up at 5:15 to swim before work, while I am a night owl and like to stay up late. She gets cold at 70 degrees while I will wear shorts outside as long as it's above 50. Mostly, we have been able to work out compromises. In the morning she uses one of the spare bathrooms so I can fall back asleep, and at night I cuddle with her when she goes to bed (around 9:30) and then get up after she is asleep. We kept her heated waterbed so she can use that on nights when I get home late, then I wake her up and she moves to our regular bed.
For the most part, any changes or new requirements have been implemented by agreement, and everything has proceeded smoothly. I believe a large part of the reason was the careful selection process used to choose the two partners who function within the system. Having properly matched individual components of a system with respect to the overall system functional requirements is one of the by-products of a well managed project.
System Deployment
For the purposes of this paper, system deployment is defined as the wedding on May 11, 1996. (See our wedding page for details on this outrageous event) Since we view getting legally married as merely a formality that will have little practical impact on our present lives, I have limited the scope of the system deployment tasks to the wedding itself (non- deployment legal issues such as consolidating insurances are considered part of long term maintenance and support). We have developed a schedule that addresses various self-imposed constraints on when tasks need to be accomplished. Our primary scheduling constraints deal with our work and school schedules. We both expect to be very busy in late spring and hope to complete most of the tasks well before May. Since our wedding is going to be very informal, the necessary tasks and schedule are shown in the following table. I have identified and obtained a computer program to support this effort.
Task Schedule
Obtain location Already done
Entertainment (DJ) Booked.
Meeting to discuss music needs to be scheduled
Invitations Prepare and mail by Feb. 11, process as received
Guest accommodations
(hotel block reservation) Feb. 11
Flowers Make arrangements by March 11
Wedding attire Select material by Jan 1
Place order by Feb. 1
Receive by April 1
License and officiant As soon after 60 days prior to deployment as possible
(constraint imposed by the state of Virginia)
Food and cake Pick caterer by Jan 1, order cake by April 1
Marriage and Beyond - An Ongoing Process
"Marriage is not a product, it's a kit. You don't buy it, you build it."(16) All the evidence to date indicates that Cathy and I have done a good job in preparing the system for actual deployment. However, good systems engineering management includes more than just deploying a working system. "A complicating aspect of evolutionary systems is that requirements satisfied in earlier stages of evolution may no longer be viewed by users as necessary, while entirely new ones may arise."(17) In order to periodically perform system assessment, various measures of effectiveness must be defined and measured. Then, a procedure for managing and implementing changes based on these assessments must be designed and followed. Support and maintenance plans must be established and followed to keep the system functioning smoothly. Finally, no system lasts forever. Plans must be made for eventual system retirement or disposal.
Assessment and Measures of Effectiveness
Cathy and I have discussed various criteria by which our relationship can be assessed for success. Not all can be easily quantitatively measured; in some cases the measurement is simply positive or negative feedback from one person to the other. Here is our current list:
Measure of Effectiveness Criteria for Satisfaction
Partner's happiness Reported qualitatively
Financial Status Needs better periodic measure, long term goal is retirement in 15 years
Number of fights per month One, at most. Target is zero.
Number of romantic encounters per week 3, minimum. May vary depending on external factors
Number of days per week having at least one hour of "together" time for talking or just relaxing 3, minimum. Target would be 5.
By these measures, we have been very successful to date. I am quite happy with our relationship, and I believe Cathy is also. We have a solid financial base to start from, and I estimate our incomes and net worth place us well above average for our age group (based on general knowledge I have from keeping up with financial news). In one and a half years we have not had a single fight or even a serious disagreement (hard to believe, but true). And we have easily satisfied the last two items.
At present, Cathy and I have no formal schedule for performing system assessments. Given the frequency at which we talk, most of our measures of effectiveness will be addressed informally at least a couple of times per month. While this may appear to be an unstructured plan, it is consistent with our mutually developed system requirements, and more importantly, has been tested and proven to work. There is a recognition that a more quantitative measure of financial status is needed in order to stay on track for the long term goal and various options have been discussed, including consulting a financial planner.
Maintenance and Support
Systems engineering management includes more than just acquiring a system that meets the original need. "Although a system may be designed and produced with the required effectiveness characteristics incorporated, these characteristics need to be retained for the duration of the life cycle through the accomplishment of good maintenance and support practices."(1 As I see it, there are three main activities for our system that fall into the maintenance and support category. These are staying employed, staying in good health, and keeping up with our individual hobbies.
Although Cathy and I presently have good jobs, the future is by no means certain (although since she works as a teacher for the county her job is fairly secure). I work as a systems engineer for MITRE; my job security is probably above average given the status of the contract I am presently working under and MITRE's corporate history. As part of a long term plan, both of us are presently enrolled in masters programs at GMU to increase both job security and job mobility. In fact, my decision to go back to school this fall was probably 80% knowing I should and 20% really wanting to. I had to trade off losing some of my free time vs. improving my job potential and decided that it was more important to go back to school.
Maintaining good health involves such things as exercise and having a good diet. I belong to a health club; Cathy swims nearly every morning, and we often go for walks together (a dual function, since we can also use that time for system assessment if we choose). Future plans may include taking cooking classes that will help us prepare interesting and healthy meals.
Keeping up with our independent hobbies is important since it represents a large part of us each maintaining a separate life outside the relationship. One of our primary operational requirements is that one person will not necessarily be responsible for entertaining the other, and to support this it is important that each person independently keep our own interests that we can do separately.
System Retirement
No system lasts forever, and good systems engineering management practice requires that plans be formulated for system retirement and disposal. Our system can end in two ways: either in divorce or when one partner dies. Both of us have estimated the probability of divorce to be very low, despite general statistics to the contrary. This is a reliability issue, and in our case the reliability of the system has been built into the design by choosing components wisely.
Our contingency plan for divorce is simple; we are relying on the other person to act reasonably if it does happen. This assumption is based on many of the personal attributes that we both required of the other person. Since we will not have children, the only real issue is how assets would be divided. The only real planning that could be done to address this contingency is to have a pre-nuptial agreement on managing assets. Since nearly all the financial risk with respect to this issue is mine (assetwise, I have significantly more than Cathy does), I have to weigh the dollar (and emotional) cost of having a legal agreement against the probability of us ever getting divorced and trusting Cathy to act in the manner that she has told me she would. I have decided a pre-nuptial agreement is not necessary.
Planning for the other case of system retirement falls under the category of estate and tax planning, plus various retirement plan and insurance issues. We have done no formal planning to date other than some related activities that support planning for retirement. There is no schedule or formal plan to address these issues, although we both realize that one will eventually be necessary. Given other management activities that will be happening in the next year, I doubt any action will be taken on this issue before then. With a few tasks related to this issue already completed (insurance coverages through work, beneficiary changes, etc.), we feel delaying the planning is an acceptable risk.
Conclusions and Recommendations
I thought the first part of the process (up until Cathy and I decided to be permanent) lent itself very well to a systems engineering management approach but after that it became much more difficult to apply an orderly process. I believe part of that is due to the fact that the first half was centered around my requirements only, while once Cathy and I became a couple there were two simultaneous evaluations (hers and mine) being performed. In addition, our interpersonal relationship dynamics tend to be anything but orderly, since the basis for our interaction is flexibility and tolerance.
Individual aspects of our relationship have system engineering parallels but our unstructured (but effective) approach to the relationship makes it difficult to apply the entire systems engineering management process as a whole. I did not feel that every system engineering management principle was applicable to this process. For example, a life cycle cost analysis was not needed since monetary cost was not an issue (I was not buying anything, and any associated "costs" to my lifestyle were reflected in my requirements).
From a systems engineering management point of view, I believe this has been as well managed a project as realistically possible, given the constraints of dealing with real people. The probability of the system meeting or even exceeding operational expectations appears quite high. This estimate is based on the extremely successful ongoing final acceptance testing and the fact that all effectiveness measures are being satisfied. To date, no significant problems or even potential for problems has arisen. We also have supporting data from observing and comparing our system to other systems, as well as obtaining independent feedback from our friends.
The only recommendations would be to adhere to the established plans, schedule and then execute future tasks that have been identified, continue system assessments, and modify the system as necessary based on assessment results.
Postscript
It's now several years later and everything is going great. We have had very few, if any, real fights, and only a couple of serious disagreements, and life together is always fun. This is no doubt highly related to our sensible decision to remain 100% CHILDFREE, and raise plants instead of rugrats.
References
1. Miles, Ralph, F., Jr., Systems Concepts: Lectures on Contemporary Approaches to Systems, John Wiley & Sons, Inc., 1973.
2. Federal Acquisition Regulation, U.S. Government Printing Office, 1988.
3. Sage, Andrew, Ph.D., "The Many Faces of Systems Engineering", Journal of NCOSE, Vol. 1, No 1, July-Sept. 1994, p 45.
4. Blanchard, Benjamin S., Systems Engineering Management, John Wiley and Sons, Inc., New York, 1991, p 21.
5. Trotter, Robert, "The Three Faces of Love", Psychology Today, Sept. 1986.
6. ibid. (quote from Robert Sternberg)
7. Sills, Judith, How to Stop Looking for Someone Perfect and Find Someone to Love, Ballantine Books, New York, 1984.
8. Sills, Judith, A Fine Romance, Ballantine Books, New York, 1987.
9. DeAngelis, Beverly, Are You the One for Me, Dell Publishing, New York, 1992.
10. Rechtin, Eberhard, Systems Architecting: Creating and Building Complex Systems, Prentice Hall, Inc., New York, 1991.
11. Pugh, S., Total Design, Addison-Wesley, Menlo Park, 1991.
12. Beam, Walter, Ph.D., "Evolutionary Systems: Arguments for Altered Processes and Practices", Journal of NCOSE, Vol. 1, No 1, July-Sept. 1994, p 115.
13. Sills, How to Stop Looking for Someone Perfect and Find Someone to Love, p 46.
14. Washingtonian Magazine, July 1994.
15. DeAngelis, Are You the One for Me, p 366.
16. Sills, A Fine Romance, p 265.
17. Beam, p 115.
18. Blanchard, p 61.
Real Life Steps System Engineering Concepts
Deciding you want a permanent partner Need statement in engineering
Defining what you want in a partner and a relationship Requirement analysis and specifications, conceptual design, and risk management plan.
Determining methods for meeting potential mates Evaluation of alternatives, cost, and schedule management.
Dating different people Preliminary design and prototyping, tradeoff studies, and modification of requirements.
Determining you have found a possible partner` To tradeoffs, multi-criteria analysis evaluation, and detailed design, test, and evaluation.
Getting engaged Refinement of system operational specifications and final acceptance testing.
Getting married System deployment and continuous operational testing.
Staying employed, saving money, etc. System maintenance and support and measures of effectiveness.
Resolving differences System assessment modification planning and change implementation.
Divorce Planning for expected or premature system retirement.
Engineering Concepts to Apply to Your Love Life
Engineering as a discipline involves the transformation from an original system concept into the finished product or satisfaction of the original need. Here are highlights of a "A Systems Engineering Approach to Dating and Relationships", written by Larry Kahn, as well as a link to the article in it's entirety.
Each real life step in dating can be applied to a common practice in engineering:
Deciding you want a permanent partner equates to the need statement in engineering.
Defining what you want in a partner and a relationship equates to the requirement analysis and specifications, conceptual design, and risk management plan.
Determining methods for meeting potential mates equates to evaluation of alternatives, cost, and schedule management.
Dating different people equates to preliminary design and prototyping, tradeoff studies, and modification of requirements.
Determining you have found a possible partner equates to tradeoffs, multi-criteria analysis evaluation, and detailed design, test, and evaluation.
Getting engaged equates to refinement of system operational specifications and final acceptance testing.
Getting married equates to system deployment and continuous operational testing.
Staying employed, saving money, etc., equates to system maintenance and support and measures of effectiveness.
Resolving differences equates to system assessment modification planning and change implementation.
Divorce equates to planning for expected or premature system retirement.
Whether you're an engineer or don't know the first thing about the subject, this will get you started on understanding the similarities.
作者：功夫王 在 海归酒吧 发贴, 来自【海归网】 http://www.haiguinet.com
|
|
|
| 返回顶端 |
|
 |
|
-
 庵拚“博导“的巨献：献给“狼多肉少”的鬼谷中国工程师 ZT (超长但有用) -- 功夫王 - (39814 Byte) 2005-1-13 周四, 15:21 (3014 reads)
|
|
|
|
您不能在本论坛发表新主题, 不能回复主题, 不能编辑自己的文章, 不能删除自己的文章, 不能发表投票, 您 不可以 发表活动帖子在本论坛, 不能添加附件可以下载文件, |
|
|
