CC BY
44
8. Gibson, C. G. and Marsh, D.: On the Geometry of Geared 5-bar Motion, Journal
ofMechanical Design, 112, (4), pp. 620-627,1990. rJenerate the
9. Gibson, C. G., Marsh, D. and Xiang, Y, An Algorithm Xo Generate^the
Transition Curve of the Planar Four-bar Mechanism, Mechanism and Machi ry,
mPriOtGibson, C. G. and Newstead, P. E„ On the Geometry of the Planar 4-Bar Mechanism, Acta Applicandae Mathematicae, 7, pp. j 13-135, • inkace The
11.Hrones, J. A and Nelson, G. L.: Analysis of the Four-bar Linkage,
Technology Press of MIT and Wiley, New York, 1951. iTniwercitv Press 1978.
12. H5t, K. H.: Kinematic Synthesis of Mechanisms.Oxford
[13] Muller, R.: Translations, Kansas State University Buletin 46 (6) Spec P No. 21,1962. [14] Torfason, L. E. and Armed, A.: Mechanism and Machine Theory, 13,
197813.Wang, D. and Xiao, D.: Distribution of c°Mer for Crank-Rocker
Linkages, Mechanism and Machine Theory, 28, (5), pp. 671- > • . Q ^ jw0
14.Xiang, Y.: Bifurcations of Singularities of Planar Lmkages with One and two Degrees of Freedom, Ph.D thesis, Napier University, Edinburgh w.
YAK 658.512.2
Chauncey Powis SOFTWARE PROCESS: Presentation and Use
The Software Process can be represented byfour strategic forces. Each force can be described by multiple factors. This model of the Software Process can be used to compare Software Engineering Methodologies. The description offerees byfactors can provide a means for analysis of existing or proposed Software Processes helping to ocumen strengths and weaknesses.
The process of developing engineering and business software has become a field in the world today. RAD (Rapid Application Development) and 00 (Uiyeci Oriented) development methodologies have become common technical terms, ut ow well do these or other concepts fill our current and future software development neeasr This paper poses a frame work of forces based upon subordinate factors on which development methodologies may be compared. An effective Software Process is dependent on the presentation and use of any development methodology used today.
A desirable Software Engineering Methodology must consider and attempt to
reconcile four strategic forces to emerge and remain in the field software engineering. I tie
four forces are: Tangible Quality, Intangible Quality, Time/Amount, and Business
Economics. This is a complex relationship of forces where maximizing the Process
Completeness factor in the Tangible Quality force may limit the Early Usable Results
factor in the Time/Amount force. Each of the four Software Process forces will be briefly
discussed with their supporting factors. Suggested initial questions are also included with
each factor. These questions may be applicable prior to, during, or at the completion ot all projects.
Tangible Quality Force
thesJf6 TangibIe Quality Force contains factors that are semi-subjective in nature, but nro' /TSk arC cr't'ca* t0 t*ie Software Process effort that is necessary to complete a fo-^ factors are more easily measured than the factors in the Intangible Quality
Ease of Understanding Factor
As a project is formed, the Software Process, the terms/definitions, and procedures that support the project must be understood by all participants in the project. Is the Software Engineering Methodology difficult to understand at the individual, group and departmental levels?
Involvement Factor
Software Process understanding should not be limited to the System Engineers and Software Engineers. This understanding is crucial to a project's success Prelect Managers, Clients, Users, System Engineers, Software Engineers, InformaU Technology Management, Client Management, and User Management must all understand the Software Process. The Business buy-in can be so great that Software Process and Business Process can begin to merge. Are all of the right groups and department* involved?
Measurability Factor
The Software Process must collect measurable tangible statistics collected. These measurements are the values in which any one implementation of a Software Process cai be compared with another. Measurements should be gathered at all levels that a business wishes to compare the Software Process in the future. Are measurements in place at th< appropriate granularity?
Repeatability Factor
Once a business or organization has implemented the Measurability Factor, at one of more levels and two or more projects have passed predetermined statistical extraction points. Process Repeatability can be determined at the sampled granularity level. Whai degree of process repeatability is applicable to a project?
Completeness Factor
The completeness of a Software Process can greatly vary the cost, stability, documentation, maintainability, and expandability of any software produced from i project. It is not prudent to just optimize all of these attributes, but to set corporate of organizational standard levels. It is also desirable to allow projects to have some leeway so as to enable the Software Process to "Fit" the problem. Does the planned Completeness Factor "Fit" the problem and intended product lifecycle? How did tht Completeness Factor vary from the planning to the implementation stages of the project?
Intangible Quality Force
The Intangible Quality Force contains factors that are subjective in nature, but ar< critical to the Software Process effort that is necessary to complete a project.
These factors are more difllcult to measure than the factors in the Tangible Quality Force.
Communication Factor
A Software Process should help communications should be at and across ma y viems aiMj successes. How was
should honestly convey generdHo« could jsuccessful communication implemented? was comn communication have been improved on the proj
The "They" Syndrome Factor
thp "Thev" Syndrome. Any software or A Software Process should not departments, or organizations too
business process that segments or stratifies gr p* ointing. This is not to imply that strongly runs the risk of paralysis and full ^efingCT P s8ib,Htles, but that attitudes individuals and organizations do not have m suooorted by the Software Process
among individuals must be of a cooperative n ’I'. CT0SS departmental issue What was the difference in the level «V^rT^índrome? resolution compared to rationalizations of the y
The "Win" Factor
The "Win" Factor is much noticed, but tobe pa«
,han * “"”r,ure'
individuals, groups, and departments have the m
Time/Amount Force
The Time/Amount Force contains factors that can he^Umit, measure, o Software Process effort that is necessary to comple e p
Fit the Problem Factor
«t he able to fit the problem set The Software Process chosen by an organizationm other organizations,
of the organization. 00 development may be the P ■ methodology fails to different departments may need flexibility or ngi n a higher price for the
fill. Multiple Software Engineering Methodologies v large organizations,
organization in people and money, but may be unavo ftware process help enable
Does the Software Process "Fit" the problem? Did the bottwarc problem resolution?
Scalability Factor
, _ (preferably one) Software An organization should strive for a low num tQ many project sizes.
Engineering Methodology. The chosen methodology „out) to an enterprise effort,
Any Software Process that claims scalability , from a «ma p f Software Process?
should be carefully scrutinized. Was the project size s pp
Did the project suffer from scope creep?
Inherent Completion Speed Factor
Some Software Processes claim and demonstrate «p¡t» a wide range of
of these Software Processes may be less scaleable and may not r
problems. Was the total project completed ahead of schedule? Was the software process a factor in the completion time of the project?
Early Testability Factor
The ability for a Software Process to provide for testing of data designs, business processes, or software designs is a great advantage. This provides the project with early validation and permits corrective action early in the life of a project. Did the software process support or enable early testing?
Early Results Factor
A Software Process that can demonstrate early usable results will be more likely to succeed. Any software that can be used or demonstrated early on in a project will increase the momentum of the project. Did the project demonstrate any early usable results? This may be a yes even if the total project was on time or late. Was the Software Process a factor in any early results.
Business Economics Force
The Business Economics Force contains factors that describe cash outlays or direct returns. This force is the most powerful of all four. It takes into account the bottom line, without which a business or organization will fail to survive for any period of time.
Capital Factor
The Capital Factor is described by resources (normally cash or credit) necessary for a project that have reusability or may be depreciated. What is the capital cost for the project?
Expense Factor
The Expense Factor is described by resources (normally cash or credit) necessary for a project that have no reusability. What is the expense cost for the project?
Business Value Factor
Most projects provide a tangible business value in return. This return of resources can normally be described as a cash return or savings over a period of time. This cash return or savings is the Business Value Factor. What business value does the project have? Is the Capital Factor and Expense Factor offset by the Business Value Factor?
Human Resource Cost Factor
This factor is described by the human resources necessary to begin, provide for, and complete a project. The scalability of humans to a project is not linear. This is a very complex problem that has dependencies such as, but not limited to: hours per day per individual, number of individuals, communications effectiveness, individual skills, and the size/complexity of the project. What is the headcount projection for the project? What was the headcount for the project through completion?
Decision Cost Recognition Factor
The recognition of what, when, where, why, and how much decisions change the costs on a project. This factor should be documented on all projects, but seldom to much extent. Every project should recognize that minimizing any one cost will influence one or more factors. Additionally, time frames for savings (long term vs. short term) are decision cost points and should be documented. What decisions changed the cost of the project and to what extent?
Conclusion
Software Engineering Methodology results have varied wildly in implementation, definition, project size, and success from industry experiences and observations. Objective examination and documentation of success and failures is a critical part of furthering development methodology paths for the future. Documentation of the results may help organizations and teams plan for or delay methodology implementations. This is a valuable process for organizations involved in and organizations considering
methodology changes. ... u
Information Systems need to be able to adapt themselves to the business world as it changes. The businesses that are able to exploit these changes in more rapid and more repeatable ways will lead or dominate future markets of the world. These businesses are not just information and communication businesses. All world's markets will be touched by Information Systems in the future. As we help study, understand, and improve the Software Process, we will help to improve the interface between a growing global society &nd the changing world marketplace. The use of this model for measuring our Software Processes can pave the path to our future Software Process.
УДК 681.324
В.Ф.Гуэик, М.Ю.Поленов, С.М.Гушанский, В.А.Калнев Комплексный иерархический подход к исследованию и проектированию
систем
Анализ многих работ, связанных с проблемой проектирования вычислительных систем (ВС), показывает, что традиционным является метод описания и моделирования систем, характеризующийся преимущественным исследованием аппаратных средств и определением программного о еспечения в обобщенной форме. При исследовании многопроцессорных вс, имеющих проблемную ориентацию (ПОВС), анализу программного обеспечения следует Уделить особое внимание, поскольку для данных систем необходимо учитывать ориентацию на заранее определенный класс решаемых задач. Таким о раз , является актуальной задача разработки средств автоматизированного исследования и проектирования, учитывающих особенности организации
В качестве решения данной проблемы предлагается комплексный алгоритме ориентированнный подход к разработке ВС. В отличие от широко используемых методов описания вычислительных систем, предлагаемый подход х®Р?*ТДРизУетс* Детальной предварительной проработкой алгоритмов, решаемых на ПОВС задач, с их последующим отображением на архитектуру системы.
