−Be skeptical about silver bullets,

−
Be skeptical about silver bullets
, and one-size-fits-all solutions.
From the 1990’s
+
Time is money
. People generally invest in software to get a
positive return. The sooner the software is fielded, the sooner
the returns come – if it has satisfactory quality.
+
Make software useful to people
. This is the other part of the
definition of “engineering.”
−
Be quick, but don’t hurry.
Overambitious early milestones
usually result in incomplete a
nd incompatible specifications
and lots of rework.
From the 2000s
+
If change is rapid, adaptability trumps repeatability
.
+
Consider and satisfice all of the stakeholders’ value
propositions
. If success-critical stakeholders are neglected or
exploited, they will generally counterattack or refuse to
participate, making everyone a loser.
−
Avoid falling in love with your slogans.
YAGNI (you aren’t
going to need it) is not always true.
For the 2010’s
+
Keep your reach within your grasp
. Some systems of systems
may just be too big and complex.
+
Have an exit strategy
. Manage expectations, so that if things go
wrong, there’s an acceptable fallback.
−
Don’t believe everything you read.
Take a look at the
downslope of the Gartner rollercoaster in Figure 10.
4.2
Some Conclusions for Software
Engineering Education
The students learning software engineering over the next two
decades will be participating their profession well into the
2040’s,
2050’s, and probably 2060’s. The increased p
ace of change
continues to accelerate, as does the complexity of the software-
intensive systems or systems of systems that need to be perceptively
engineered. This presents many serious but exciting challenges to
software engineering education, including:
•
Keeping courses and courseware continually refreshed
and up-to-date;
•
Anticipating future trends a
nd preparing students to deal
with them;
•
Monitoring current principles and practices and
separating timeless principles from out-of-date practices;
•
Packaging smaller-scale educational experiences in ways
that apply to large-scale projects;
•
Participating in leading-ed
ge software engineering
research and practice, and incorporating the results into
the curriculum;
•
Helping students learn how to learn, through state-of-the-
art analyses, future-oriented educational games and
exercises, and participation in research; and
•
Offering lifelong learning opportunities as software
engineers continue to practice their profession
Acknowledgements and Apologies
This work was partly supported by NSF grants CCF-0137766 for
the IMPACT project, my NSF “Value-Based Science of Design”
grant, and the Affiliates of the USC Center for Software
Engineering.
I also benefited significantly from interactions with software
pioneers and historians at the 1996 Dagstuhl History of Software
Engineering seminar, the SD&M Software Pioneers conference, and
the NSF/ACM/IEE (UK) IMPACT project.
Having said this, I am amazed at how little I learned at those events
and other interactions that has made it into this paper. And just
glancing at my bookshelves, I am embarrassed at how many
significant contributions are not represented here, and how much the
paper is skewed toward the U.S. and my own experiences. My
deepest apologies to those of you that I have neglected.
5.
REFERENCES
[1]
ISO. Standard for Information Technology – Software Life
Cycle Processes. ISO/IEC 12207, 1995.
[2]
ISO. Systems Engineering – System Life Cycle Processes.
ISO/IEC 15288, 2002.
[3]
FCIO (Federal CIO Council), A Practical Guide to Federal
Enterprise Architecture, Version 1.0, FCIO, Washington,
DC, February 2001. zaqi4.
[4]
Alford, M.W., Software Re
quirements Engineering
Methodology (SREM) at the Age of Four,
COMPSAC 80
Proceedings, (October 1
980) pp 366-374.
[5]
Anthes, G., The Future of IT.
Computerworld
, (March 7,
2005) 27-36
[6]
Aron, J.
Software Engineering
, NATO Science Committee
Report, January 1969.
[7]
Arthur, W. B., Increasing Returns and the New World of
Business.
Harvard Business Review
(July/August, 1996)
100-109
[8]
Baker, F. T. Structured programming in a production
programming environment.
In Proceedings of the
international Conference on Reliable Software.
Los
Angeles, California, April 21 - 23, 1975.
[9]
Balzer, R.M. A Global View Of Automatic Programming,
Proc. 3rd Joint Conferen
ce On Artificial Intelligence
,
August, 1973, pp. 494-499.
[10]
Balzer, R. M., T. E. Cheatham, and C. Green, Software
Technology in the 1990's: Using a New Paradigm,
Computer
, Nov. 1983, pp. 3945.
[11]
Basili V. R. and M. V. Zelkowitz, Analyzing medium scale
software development,
Third International Conf. On
Software Engineering
, Atlanta, Ga. (May, 1978) 116-123.
[12]
Bass, L., Clements, P., and Kazman, R.
Software
Architecture in Practice
, Addison-Wesley, 1998.
[13]
Bass, L. and Coutaz, J.,
Developing Software for the User
Interface
, Addison Wesley, 1991
[14]
Beck, K. Extreme Programming Explained, Addison-
Wesley, 2000
[15]
Belady, L. A. and Lehman, M. M., Characteristics of large
systems, in
Research Directions in Software Technology
,
P.Wegner (editor), MIT-Press,
Cambridge, Massachusetts,
1979
[16]
Benington, H. D., Production of Large Computer Programs,
Proceedings of the
ONR Symposium on Advanced Program
Methods for Digital Computers
, June 1956, pp. 15 - 27.
Also available in Annals of the History of Computing,
October 1983, pp. 350 - 361.
[17]
Berners-Lee, T.,
World Wide Web Seminar
.
http://www.w3.org/Talks/General.html (1
991)
[18]
Berners-Lee, T., Cailliau, R., Luotonen, A., Frystyk , H.,
Nielsen, F., and Secret, A.. The World-Wide Web, in
Comm. ACM
(CACM), 37(8), 76-82, 1994.
[19]
Best Current Practices: Software Architecture Validation,
AT&T Bell Labs, 1990.
[20]
Biffl, S., Aurum, A., Boehm, B., Erdogmus, H.,
Gruenbacher, P. (eds.).
Value-Based Software Engineering
.
Springer Verlag (2005)
[21]
Bjorner, D., On the use of formal methods in software
development. In Proceedings of the 9th International
Conference on Software Engineering (Monterey, California,
United States), 1987.
[22]
Boehm, B., Software and its impact: a quantitative
assessment.
Datamation
, pages 48-59, May 1973.
[23]
Boehm, B. W., J. R. Brown, H. Kaspar, M. Lipow, G. J.
MacLeod, M. J. Merritt,
Characteristics of Software
Quality
, TRW Software Series TRW-SS-73-09, December
1973.
[24]
Boehm, B., Software engineering.
IEEE Trans. Computers
,
100(25):1226-1241, 1976.
[25]
Boehm, B., Software Engineering: As it is. ICSE 1979: 11-
21.
[26]
Boehm, B.,
Software Engineering Economics
, Prentice-Hall
1981
[27]
Boehm, B., Standish, T. A. Software Technology in the
1990's: Using an Evolutionary Paradigm.
IEEE Computer
16(11): 30-37 (1983)
[28]
Boehm, B., A Spiral Model of Software Development and
Enhancement,
Computer
, May 1988, pp. 61-72.
[29]
Boehm B., An Early Application generator and Other
Recollections, in Glass, R. L.,
In The Beginning:
Recollections of Software Pioneers
, IEEE CS Press, 1988
[30]
Boehm, B.,
Software Risk Management
, CS Press, Los
Alamitos, Calif., 1989.
[31]
Boehm, B. and Ross, R., Theory-W Software Project
Management: Principles and Examples,
IEEE Trans. SW
Engineering
., July 1989, pp. 902-916.
[32]
Boehm, B., A Spiral Model for Software Development and
Enhancement,
Computer
, vol. 21, May 1988, pp. 61-72.
[33]
Boehm, B., Anchoring the Software Process,
IEEE
Software
, Vol. 13, No. 14, July 1996
34]
Boehm, B., Managing Software Productivity and Reuse.
Computer
32, 9 (Sep. 1999), 111-113
[35]
Boehm, B., Brown, A.W, Basili, V. and Turner R., Spiral
Acquisition of Software-Intensive Systems.
CrossTalk
, May
2004, pp. 4-9.
[36]
Boehm, B., Turner, R.,
Balancing Agility and Discipline
,
Addison Wesley (2004)
[37]
Boehm, B., Jain, A. An Initial Theory of Value-Based
Software Engineering. In: Auru
m, A., Biffl, S., Boehm, B.,
Er-dogmus, H., Gruenbacher, P. (eds.):
Value-Based
Software Engineering
, Springer Verlag (2005)
[38]
Boehm, B., Some Future Trends and Implications for
Systems and Software Engineering Processes,
Systems
Engineering
, vol. 9, No. 1, 2006, pp 1-19.
[39]
Boehm, B. and Lane, J., 21
st
Century Processes for
Acquiring 21
st
Century Software Intensive Systems of
Systems,
Cross Talk
, May 2006 (to appear)
[40]
Böhm, C. and Jacopini, G. Flow diagrams, turing machines
and languages with only two formation rules.
Comm. ACM
9, 5 (May. 1966), 366-371
[41]
Booch, G., Rumbaugh, J. and Jacobson, L.
The Unified
Modeling Language User Guide
. Addison-Wesley
Longman Inc., 1999.
[42]
Brooks, F. P., The Mythical Man-Month, Addison Wesley,
1975.
[43]
Brooks, F. P., No silver bullet: Essence and accidents of
software engineering.
IEEE Computer
, 20(4):10-19, April
1987.
[44]
Buxton J. N. and Randell B. (Eds.)
Software Engineering
Techniques: Report on a Conference Sponsored by the
NATO Science Committee
, Rome, Italy, 27-31 Oct. 1969.
Scientific Affairs Division, NATO, Brussels (May 1970).
[45]
PDL/74 Program Design Language Reference Guide
(Processor Version 3), Caine Farber Gordon Inc., 1977
[46]
Charette, R. N., Software Engineering Risk Analysis and
Management, McGraw-Hill, 1989.
[47]
Clemm, G., The Workshop System - A Practical
Knowledge-Based Software Environment,
Proceedings of
the ACM SIGSOFT/SIGPLAN Software Engineering
Symposium on Practical Software Development
Environments
, ACM SIGPLAN Notices, 13, 5, pp. 55-64
(Nov 1988).
[48]
Constantine, L. L. The Programming Profession,
Programming Theory, and Programming Education.
Computers and Automation
17,2 (Feb. 1968) pp. 14-19.
[49]
Crawford, D. Editorial Pointers.
Comm. ACM
(October,
2001) 5.
[50]
Cooper, J. D.,
Characteristics of the Average Coder
,
personal communication, May 1975.
[51]
Conrow, E. H., Risk Management for Systems of Systems,
CrossTalk
, v. 18, n. 2 (February 2005), pages 8-12.
[52]
Cusumano, M. A. The Software Factory: A Historical
Interpretation.
IEEE Softw.
6, 2 (Mar. 1989), 23-30

Kết quả (Việt) 1:

−Được hoài nghi về bạc đạn, và cỡ giải pháp.Từ những năm 1990+Thời gian là tiền. Mọi người thường đầu tư vào các phần mềm để có được mộttrở lại tích cực. Các phần mềm được đưa ra sớm hơn, sớm hơntrả lại đi-nếu nó có chất lượng đạt yêu cầu.+Làm cho phần mềm hữu ích cho những người. Điều này là một phần còn lại của cácđịnh nghĩa của "kỹ thuật."−Được nhanh chóng, nhưng không vội vàng.Các cột mốc đầu overambitiousthường kết quả trong không đầy đủ mộtnd chi tiết kỹ thuật không tương thíchvà rất nhiều làm lại.Từ thập niên 2000+Nếu thay đổi nhanh chóng, có khả năng hơn hẳn lặp.+Xem xét và satisfice tất cả các bên liên quan giá trịđề xuất. Nếu thành công quan trọng các bên liên quan được bỏ rơi hoặckhai thác, họ sẽ nói chung phản hay từ chốitham gia, làm cho tất cả mọi người một thua.−Tránh rơi vào tình yêu với khẩu hiệu của bạn.YAGNI (bạn khôngsẽ cần nó) là không luôn luôn đúng.Cho các 2010's+Giữ tầm tay của bạn trong tầm tay của bạn. Một số hệ thống của hệ thốngcó thể chỉ là quá lớn và phức tạp.+Có một chiến lược thoát. Quản lý mong đợi, để nếu mọi thứ đisai, đó là một dự phòng chấp nhận được.−Không tin rằng tất cả mọi thứ bạn đọc.Có một cái nhìn tại cácdownslope của rollercoaster Gartner hình 10.4.2Một số kết luận cho phần mềmGiáo dục kỹ thuậtCác sinh viên học tập công nghệ phần mềm trong hai tiếp theothập kỷ sẽ tham gia nghề nghiệp của họ vào các2040,2050's, và có lẽ của 2060. Tăng pace của thay đổitiếp tục để tăng tốc, như sự phức tạp của phần mềm-Hệ thống chuyên sâu hoặc hệ thống của hệ thống mà cần phải perceptivelythiết kế. Điều này trình bày nhiều thách thức nghiêm trọng nhưng thú vị đểgiáo dục công nghệ phần mềm, bao gồm:•Giữ các khóa học và courseware liên tục làm mớivà thông tin mới nhất;•Dự đoán xu hướng tương lai mộtnd chuẩn bị sinh viên để đối phóvới họ;•Giám sát hiện tại nguyên tắc và thực tiễn vàtách nguyên tắc vô tận từ out-of-thực hành;•Bao bì quy mô nhỏ hơn giáo dục kinh nghiệm bằng cáchmà áp dụng cho các dự án quy mô lớn;•Tham gia vào hàng đầu-edGE công nghệ phần mềmnghiên cứu và thực hành, và kết hợp các kết quả vàochương trình giảng dạy;•Giúp sinh viên tìm hiểu làm thế nào để tìm hiểu, thông qua nhà nước-của-các -nghệ thuật phân tích, theo định hướng tương lai trò chơi giáo dục vàbài tập, và tham gia vào nghiên cứu; và•Cung cấp cơ hội học tập suốt đời như phần mềmkỹ sư tiếp tục thực hành nghề nghiệp của họLời cảm ơn và lời xin lỗiCông việc này một phần được hỗ trợ bởi NSF tài trợ CCF-0137766 chodự án tác động, của tôi NSF "Dựa trên giá trị khoa học của thiết kế"Grant, và các chi nhánh của Trung tâm USC phần mềmKỹ thuật.Tôi cũng hưởng lợi đáng kể từ các tương tác với phần mềmnhững người tiên phong và nhà sử học lịch sử Dagstuhl năm 1996 của phần mềmKỹ thuật hội thảo, hội nghị SD & M phần mềm tiên phong, vàdự án NSF/ACM/IEE (Anh) tác động.Có nói điều này, tôi ngạc nhiên trước như thế nào ít tôi đã học được ở các sự kiệnvà tương tác khác mà đã làm cho nó vào giấy này. Và chỉglancing tại từng kệ sách của tôi, tôi cảm thấy xấu hổ tại bao nhiêugóp phần quan trọng không được đại diện ở đây, và bao nhiêu cácgiấy sai lệch hướng tới Hoa Kỳ và kinh nghiệm của riêng tôi. Của tôilời xin lỗi sâu sắc nhất tới những người bạn mà tôi đã bỏ rơi.5.TÀI LIỆU THAM KHẢO[1]ISO. Tiêu chuẩn cho công nghệ thông tin-cuộc sống phần mềmChu kỳ quy trình. TIÊU CHUẨN ISO/IEC 12207, 1995.[2]ISO. Hệ thống kỹ thuật-hệ thống vòng đời quy trình.TIÊU CHUẨN ISO/IEC 15288, 2002.[3]FCIO (hội đồng liên bang CIO), một hướng dẫn thiết thực để liên bangKiến trúc doanh nghiệp, phiên bản 1.0, FCIO, Washington,DC, tháng 2 năm 2001. zaqi4.[4]Alford, M.W., phần mềm táiquirements kỹ thuậtPhương pháp (SREM) tại bốn, tuổiCOMPSAC 80Thủ tục tố tụng, (1 tháng 10980) pp 366-374.[5]Anthes, G., tương lai của nó.Máy tính, (7 tháng 3,2005) 27-36[6]Aron, J.Công nghệ phần mềm, Ủy ban khoa học của NATOBáo cáo, tháng 1 năm 1969.[7]Arthur, W. B., tăng lợi nhuận và Tân thế giới củaDịch vụ doanh nhân.Harvard Business Review(Tháng bảy/tháng tám, 1996)100-109[8]Baker, F. T. lập trình cấu trúc trong vởmôi trường lập trình.Trong thủ tục tố tụng của cácHội nghị quốc tế về phần mềm đáng tin cậy.LosAngeles, California, tháng 4 21-23, năm 1975.[9]Balzer, RM Một cái nhìn toàn cầu của chương trình tự động,Proc. 3 chung ConferenCE vào trí tuệ nhân tạo,Tháng 8, 1973, tr. 494-499.[10]Balzer, R. M., T. E. Cheatham, và C. Green, phần mềmCông nghệ vào những năm 1990: bằng cách sử dụng một mô hình mới,Máy tính, Tháng 11 năm 1983, pp. 3945.[11]Basili V. R. và M. V. Zelkowitz, phân tích các quy mô trung bìnhphát triển phần mềm,Conf. quốc tế thứ ba ngàyCông nghệ phần mềm, Atlanta, Ga. (tháng 5, 1978) 116-123.[12]Bass, L., Clements, P., và Kazman, R.Phần mềmKiến trúc trong thực tế, Addison-Wesley, 1998.[13]Bass, L. và Coutaz, J.,Phát triển phần mềm cho người dùngGiao diện, Addison Wesley, 1991[14]Beck, K. Extreme lập trình giải thích, Addison-Wesley, 2000 [15]Belady, L. A. và Lehman, M. M., đặc điểm của lớnHệ thống, trongCác hướng nghiên cứu trong công nghệ phần mềm,P.Wegner (chủ biên), MIT-Press,Cambridge, Massachusetts,năm 1979[16]Benington, H. D., sản xuất chương trình máy tính lớn,Thủ tục tố tụng của cácONR hội thảo về chương trình tiên tiếnPhương pháp cho máy tính kỹ thuật số, Tháng 6 năm 1956, trang 15-27.Cũng có sẵn trong biên niên sử của các lịch sử của máy tính,Tháng 10 năm 1983, trang 350-361.[17]Berners-Lee, T.,World Wide Web hội thảo.http://www.w3.org/Talks/General.html (1991)[18]Berners-Lee, T., Cailliau, R., Luotonen, A., Frystyk, H.,Nielsen, F., và bí mật, A.. Toàn thế giới Web, trongComm. ACM(CACM), 37(8), 76-82, 1994.[19]Tốt nhất thực tiễn hiện tại: Phần mềm kiến trúc xác nhận,AT & T Bell Labs, 1990.[20]Biffl, S., Aurum, A., Boehm, sinh, Erdogmus, H.,Gruenbacher, P. (chủ biên).Dựa trên giá trị công nghệ phần mềm.Springer Verlag (2005)[21]Bjorner, D., về việc sử dụng các phương pháp hình thức trong phần mềmphát triển. Trong thủ tục tố tụng của quốc tế 9Hội nghị về công nghệ phần mềm (Monterey, California,Hoa Kỳ), 1987.[22]Boehm, B., phần mềm và tác động của nó: một định lượngđánh giá.Datamation, trang 48-59, tháng 5 năm 1973.[23]Boehm, B. W. J. R. Brown, H. Kaspar, M. Lipow, G. J.MacLeod, M. J. Merritt,Đặc điểm của phần mềmChất lượng, TRW phần mềm loạt TRW-SS-73-09, tháng mười hainăm 1973.[24]Boehm, B., công nghệ phần mềm.IEEE dịch máy tính,100 (25): 1226-1241, 1976.[25]Boehm, sinh, công nghệ phần mềm: Vì nó là. ICSE NĂM 1979:11-21.[26]Boehm, sinh,Kinh tế kỹ thuật phần mềm, Prentice-Hall1981[27]Boehm, sinh, Standish, T. A. phần mềm công nghệ trong cáccủa năm 1990: bằng cách sử dụng một mô hình tiến hóa.IEEE máy tính16(11): 30-37 (1983)[28]Boehm, sinh, một mô hình xoắn ốc của phát triển phần mềm vàNâng cao,Máy tính, Tháng 5 năm 1988, trang 61-72.[29]Boehm sinh, An ứng dụng đầu máy phát điện và khácHồi ức, trong thủy tinh, R. L.,Ban đầu:Hồi ức của những người tiên phong của phần mềm, IEEE CS Press, 1988[30]Boehm, sinh,Phần mềm quản lý rủi ro, CS báo chí, LosAlamitos, Calif, 1989.[31]Boehm, B. và Ross, R., dự án phần mềm lý thuyết-WQuản lý: Nguyên tắc và các ví dụ,IEEE dịch SWKỹ thuật., 7 năm 1989, tr. 902-916.[32]Boehm, sinh, một mô hình xoắn ốc cho phát triển phần mềm vàNâng cao,Máy tính, vol. 21, tháng 5 năm 1988, trang 61-72.[33]Boehm, sinh, thả neo trình phần mềm,IEEEPhần mềm, Vol. 13, No. 14, tháng 7 năm 1996 34]Boehm, sinh, quản lý phần mềm năng suất và tái sử dụng.Máy tính32, 9 (tháng chín 1999), 111-113[35]Boehm, sinh, nâu, A.W, Basili, V. và Turner R., xoắn ốcMua lại của hệ thống phần mềm chuyên sâu.Xuyên âm, Có thểnăm 2004, pp. 4-9.[36]Boehm, sinh, Turner, R.,Cân bằng sự nhanh nhẹn và kỷ luật,Addison Wesley (2004)[37]Boehm, sinh, Jain, A. Một lý thuyết ban đầu dựa trên giá trịCông nghệ phần mềm. Trong: Aurum, A., Biffl, S., Boehm, sinh,Er-dogmus, H., Gruenbacher, P. (chủ biên):Dựa trên giá trịCông nghệ phần mềm, Springer Verlag (2005)[38]Boehm, B., một số xu hướng trong tương lai và tác động đối vớiHệ thống và quy trình công nghệ phần mềm,Hệ thốngKỹ thuật, vol. 9, No. 1, 2006, pp 1-19.[39]Boehm, sinh và Lane, J., 21StQuá trình thế kỷCó được 21StThế kỷ mười một hệ thống phần mềm chuyên sâu củaHệ thống,Cross Talk, Tháng 5 năm 2006 (để xuất hiện)[40]Böhm, C. và Jacopini, sơ đồ dòng chảy G., máy turingvà ngôn ngữ với chỉ có hai hình thành quy tắc.Comm. ACM9, 5 (May. năm 1966), 366-371[41]Booch, G., Rumbaugh, J. và Jacobson, L.Các thống nhấtMô hình hóa hướng dẫn sử dụng ngôn ngữ. Addison-WesleyLongman Inc (1999).[42]Brooks, F. P., Mythical Man-Month, Addison Wesley,năm 1975.[43]Brooks, F. P., không có đạn bạc: bản chất và tai nạn củacông nghệ phần mềm.IEEE máy tính, 20 (4): 10-19, Tháng tưnăm 1987.[44]Buxton J. N. và B. Randell (chủ biên)Công nghệ phần mềmKỹ thuật: Báo cáo về một hội nghị tài trợ của cácỦy ban khoa học của NATO, Rome, ý, 27-31 tháng mười năm 1969.Khoa học giao Division, NATO, Brút-xen (tháng 5 năm 1970).[45]PDL/74 chương trình thiết kế ngôn ngữ tham khảo hướng dẫn(Phiên bản xử lý 3), Caine Farber Gordon Inc, 1977[46]Charette, R. N., công nghệ phần mềm phân tích rủi ro vàQuản lý, McGraw-Hill, 1989.[47]Clemm, G., Hệ thống hội thảo - một thực tếPhần mềm dựa trên kiến thức môi trường,Thủ tục tố tụng củacông nghệ phần mềm ACM SIGSOFT/SIGPLANHội thảo về phát triển phần mềm thực tếMôi trường, Thông báo ACM SIGPLAN, 13, 5, trang 55-64(Tháng 11 năm 1988).[48]Constantine, L. L. Các chương trình nghiệp vụ,Lập trình lý thuyết, và chương trình giáo dục.Máy tính và tự động hóa17,2 (tháng 2 1968) trang 14-19.[49]Crawford, D. biên tập con trỏ.Comm. ACM(Ngày,2001) 5.[50]Cooper, J. D.,Đặc điểm của Coder trung bình,truyền thông cá nhân, tháng 5 năm 1975.[51]Conrow, E. H., quản lý cho hệ thống của hệ thống, rủi roXuyên âm, v. 18, n. 2 (tháng 2 năm 2005), trang 8-12.[52]Cusumano, M. A. Nhà máy sản xuất phần mềm: Một lịch sửGiải thích.IEEE Softw.6, 2 (tháng 03 năm 1989), 23-30

Kết quả (Việt) 2:

-
Hãy hoài nghi về những viên đạn
bạc, và một trong những-size-fits-tất cả các giải pháp.
Từ năm 1990
+
Thời gian là tiền
bạc. Con người thường đầu tư vào phần mềm để có được một
trở lại tích cực. Việc sớm hơn các phần mềm được ra sân, sớm hơn
lợi nhuận đến - nếu nó có chất lượng đạt yêu cầu.
+
Làm cho phần mềm hữu ích cho mọi
người. Đây là một phần khác của
định nghĩa về "kỹ thuật".
-
Hãy nhanh chóng, nhưng không vội vàng.
Cột mốc đầu Overambitious
thường cho kết quả không đầy đủ một
thứ thông số kỹ thuật không phù hợp
và rất nhiều làm lại.
Từ những năm 2000
+
Nếu thay đổi là nhanh chóng, khả năng thích ứng Trumps lặp
lại.
+
Xem xét và satisfice tất cả các giá trị của các bên liên quan
đề
xuất. Nếu các bên liên quan thành công quan trọng đang bị bỏ quên hoặc
khai thác, họ sẽ thường phản công hoặc từ chối
tham gia, làm cho tất cả mọi người là người thua cuộc.
-
Tránh rơi vào tình yêu với những khẩu hiệu của bạn.
YAGNI (bạn không được
sẽ cần đến nó) không phải là luôn luôn đúng.
Đối với của 2010
+
Giữ tầm tay của bạn nằm trong tầm tay của
bạn. Một số hệ thống của hệ thống
chỉ có thể là quá lớn và phức tạp.
+
Có một chiến lược rút
lui. Quản lý kỳ vọng, do đó nếu mọi thứ đi
sai, có một fallback chấp nhận được.
-
Đừng tin tất cả mọi thứ bạn đọc.
Hãy nhìn vào những
downslope của rollercoaster Gartner trong hình 10
4.2
Một số kết luận về Software
Engineering Education
Các học sinh học công nghệ phần mềm hơn sau hai
thập kỷ sẽ được tham gia nghề nghiệp của họ cũng vào
của năm 2040,
của năm 2050, và có lẽ của năm 2060. Việc tăng p
ace của sự thay đổi
tiếp tục đẩy nhanh tiến độ, cũng như sự phức tạp của Software-
hệ thống thâm canh hoặc các hệ thống của hệ thống cần được perceptively
thiết. Điều này đặt ra nhiều thách thức nghiêm trọng nhưng thú vị để
giáo dục kỹ thuật phần mềm, bao gồm:
•
Giữ các khóa học và chương trình học liên tục làm mới
và up-to-ngày;
•
Dự đoán xu hướng tương lai một
thứ chuẩn bị học sinh để đối phó
với họ;
•
​​Giám sát các nguyên tắc và thông lệ hiện hành và
chia vượt thời gian nguyên tắc từ của nhật ra thực hành;
•
Bao Bì kinh nghiệm giáo dục quy mô nhỏ hơn trong cách
áp dụng cho các dự án quy mô lớn;
•
Tham gia hàng đầu-ed
ge công nghệ phần mềm
nghiên cứu và thực hành, và kết hợp các kết quả vào
các chương trình giảng dạy;
•
Giúp học sinh học cách học, thông qua nhà
nước-of-the-nghệ thuật phân tích, trò chơi định hướng tương lai giáo dục và
bài ​​tập, và sự tham gia trong nghiên cứu; và
•
Cung cấp các cơ hội học tập suốt đời như phần mềm
kỹ sư tiếp tục hành nghề
Lời cảm ơn và lời xin lỗi
công việc này một phần được hỗ trợ bởi NSF cấp CCF-0137766 cho
các dự án IMPACT, NSF của tôi "Value-Based Science of Design"
tài trợ, và các chi nhánh của Trung tâm USC cho Software
Engineering.
Tôi cũng được hưởng lợi đáng kể từ các tương tác với phần mềm
tiên phong và các sử gia ở năm 1996 Dagstuhl Lịch sử của Software
Engineering hội thảo, các SD & M hội nghị phần mềm tiên phong, và
NSF / ACM / IEE (Anh) dự án IMPACT.
Có nói này, Tôi ngạc nhiên trước cách nhỏ tôi đã học được ở những sự kiện
và tương tác khác mà đã làm cho nó thành bài viết này. Và chỉ cần
nhìn lướt qua kệ sách của tôi, tôi cảm thấy ngượng khi thấy bao nhiêu
đóng góp quan trọng không được thể hiện ở đây, và bao nhiêu
giấy bị lệch về phía Mỹ và kinh nghiệm của riêng tôi. Tôi
xin lỗi sâu sắc nhất tới những người bạn mà tôi đã bỏ quên.
5.
THAM KHẢO
[1]
ISO. Tiêu chuẩn công nghệ thông tin - Phần mềm Cuộc sống
Processes Cycle. ISO / IEC 12.207, năm 1995.
[2]
ISO. Kỹ thuật hệ thống -. Processes Hệ thống Vòng đời:
ISO / IEC 15.288, năm 2002.
[3]
FCIO (Hội đồng CIO Liên bang), Hướng dẫn thực hành liên bang
kiến trúc doanh nghiệp, Phiên bản 1.0, FCIO,
Washington,. DC, tháng Hai năm 2001. zaqi4
[4]
Alford, MW, phần mềm Re
quirements Kỹ thuật
Phương pháp (SREM) ở Age of Four,
COMPSAC 80
Proceedings, (01 tháng 10
980) pp 366-374.
[5]
Anthes, G., Tương lai của CNTT.
Computerworld, (07 Tháng 3 , 2005) 27-36 [6] Aron, J. Software Engineering, Ủy ban Khoa học NATO Report, tháng Giêng năm 1969. [7] Arthur, WB, Returns Tăng và thế giới mới của kinh doanh. Harvard Business Review (July / August, 1996) 100-109 [8] Baker, FT lập trình có cấu trúc trong một sản xuất môi trường lập trình. Trong Kỷ yếu của Hội nghị quốc tế về phần mềm đáng tin cậy. Los Angeles, California, 21-ngày 23 tháng 4, 1975. [9] Balzer, RM A Xem toàn cầu của tự động Lập trình, Proc. Phần Conferen thứ 3 ce Mở Artificial Intelligence, Tháng Tám, 1973, pp 494-499.. [10] Balzer, RM, TE Cheatham, và C. Green, phần mềm công nghệ trong năm 1990: Sử dụng một Paradigm mới, máy tính, tháng 11 năm 1983, pp. 3945. [11] Basili VR và MV Zelkowitz, Phân tích quy mô vừa phát triển phần mềm, Quốc tế thứ ba Conf. Trên Software Engineering, Atlanta, Ga. (May, 1978) 116-123. [12] Bass, L., Clements, P., và Kazman, R. Software Architecture trong thực tiễn, Addison-Wesley, 1998. [13] Bass , L. và Coutaz, J., Phát triển phần mềm cho người dùng giao diện, Addison Wesley, 1991 [14] Beck, K. cực Lập trình Giải thích, Addison- Wesley, 2000 [15] Belady, LA và Lehman, MM, đặc điểm lớn hệ thống, trong Chỉ nghiên cứu trong công nghệ phần mềm, P.Wegner (chủ biên), MIT-Press, Cambridge, Massachusetts, 1979 [16] Benington, HD, Sản xuất chương trình máy tính lớn, Kỷ yếu của Hội nghị chuyên đề ONR về Chương trình nâng cao phương pháp kỹ thuật số Máy tính Tháng Sáu năm 1956, pp 15 - 27.. Cũng có sẵn trong Biên niên sử về Lịch sử máy tính, tháng 10 năm 1983, trang 350 - 361.. [17] Berners-Lee, T., World Wide Web Hội thảo. http: // www. w3.org/Talks/General.html (1 991) [18] Berners-Lee, T., Cailliau, R., Luotonen, A., Frystyk, H., Nielsen, F., và Secret, A .. Các World-Wide Web, trong Comm. ACM (CACM), 37 (8), 76-82, 1994. [19] Thực tiễn tốt nhất hiện tại: Kiến trúc phần mềm Validation, AT & T Bell Labs, năm 1990. [20] Biffl, S., Aurum, A., Boehm, B. , Erdogmus, H., Gruenbacher, P. (eds.). Value-Based Software Engineering. Springer Verlag (2005) [21] Bjorner, D., Về việc sử dụng phương pháp hình thức trong phần mềm phát triển. Trong Kỷ yếu của 9 quốc tế Hội nghị về Công nghệ phần mềm (Monterey, California, Hoa Kỳ), năm 1987. [22] Boehm, B., phần mềm và tác động của nó: một định lượng. Đánh giá Datamation, các trang 48-59, tháng năm 1973. [23 ] Boehm, BW, JR Brown, H. Kaspar, M. Lipow, GJ MacLeod, MJ Merritt, Đặc điểm của phần mềm chất lượng, TRW Software Dòng TRW-SS-73-09, December 1973. [24] Boehm, B., phần mềm kỹ thuật. IEEE Trans. Máy vi tính, 100 (25): 1226-1241, 1976. [25] Boehm, B., Software Engineering: Vì nó là. ICSE 1979: 11- 21. [26] Boehm, B., Phần mềm Kinh tế Kỹ thuật, Prentice-Hall năm 1981 [27] Boehm, B., Standish, TA Công nghệ phần mềm trong năm 1990:. Sử dụng một Evolutionary Paradigm IEEE Computer 16 (11 ): 30-37 (1983) [28] Boehm, B., Một mô hình xoắn ốc của phát triển phần mềm và Enhancement, máy tính.., tháng năm 1988, pp 61-72 [29] Boehm B., An máy phát điện ứng dụng sớm và khác hồi ức , trong Glass, RL, In The Beginning: hồi ức của phần mềm tiên phong, IEEE CS Press, 1988 [30] Boehm, B., Quản lý rủi ro Phần mềm, CS Press, Los. Alamitos, California, 1989. [31] Boehm, B. và Ross, R., Lý thuyết-W dự án phần mềm quản lý: Nguyên tắc và ví dụ, IEEE Trans. SW Engineering., Tháng 7 năm 1989, pp. 902-916. [32] Boehm, B., Một mô hình xoắn ốc cho phát triển phần mềm và Enhancement, máy tính, vol. 21 tháng năm 1988, pp. 61-72. [33] Boehm, B., neo Quy trình phần mềm, IEEE Software, Vol. 13, số 14, tháng 7 năm 1996 34] Boehm, B., Giám Software suất và tái sử dụng. Máy tính 32, 9 (tháng 9 năm 1999), 111-113 [35] Boehm, B., Brown, AW, Basili, V. và Turner R., Spiral thu các hệ thống phần mềm chuyên sâu. crosstalk, May 2004, pp. 4-9. [36] Boehm, B., Turner, R., Balancing Agility và Kỷ luật, Addison Wesley (2004) [37] Boehm, B., Jain, A. An Lý thuyết ban đầu của Value-Based Software Engineering. Trong: Auru m, A., Biffl, S., Boehm, B., Er-dogmus, H., Gruenbacher, P. (eds.): Giá trị-Based Software Engineering, Springer Verlag (2005) [38] Boehm, B., một số xu hướng trong tương lai và ảnh hưởng đối với hệ thống và quy trình công nghệ phần mềm, hệ thống kỹ thuật, vol. 9, số 1, 2006, trang 1-19. [39] Boehm, B. và Lane, J., 21 st Processes Century cho Thu 21 st Century Software Systems chuyên sâu của Hệ thống, Cross Talk, tháng 5 năm 2006 (xuất hiện) [40] Böhm, C. và Jacopini, sơ đồ G. Flow, Turing máy và ngôn ngữ chỉ có hai quy tắc hình thành. Comm. ACM 9, 5 (May. 1966), 366-371 [41] Booch, G., Rumbaugh, J. và Jacobson, L. Unified Hướng dẫn sử dụng Modeling Language. Addison-Wesley Longman Inc., 1999. [42] Brooks, FP, The Mythical Man-Month, Addison Wesley, 1975. [43] Brooks, FP, Không bạc đạn: Essence và tai nạn của công nghệ phần mềm. IEEE Computer, 20 ( 4): 10-19, tháng Tư năm 1987. [44] Buxton JN và Randell B. (Eds). Kỹ thuật phần mềm Kỹ thuật: Báo cáo về một hội nghị tài trợ bởi Ủy ban Khoa học NATO, Rome, Ý, 27-ngày 31 tháng 10 năm 1969. Khoa học Xã Division, NATO, Brussels (tháng 5 năm 1970). [45] PDL / 74 Chương trình Thiết kế Language Reference Guide (Processor Phiên bản 3), Caine Farber Gordon Inc., 1977 [46] Charette, RN, Công nghệ phần mềm Phân tích rủi ro và quản lý, McGraw -Hill, 1989. [47] Clemm, G., Hệ thống Hội thảo - A Practical Knowledge-Based Phần mềm Môi trường, Kỷ yếu của các SIGSOFT / SIGPLAN Software Engineering ACM Hội nghị chuyên đề về thực tiễn phát triển phần mềm môi trường, ACM SIGPLAN thông báo, 13, 5, pp 55-64. (tháng 11 năm 1988). [48] Constantine, LL lập trình chuyên nghiệp, Lập trình Lý thuyết, và Lập trình Giáo dục. Máy vi tính và tự động hóa 17,2 (tháng 2 1968) pp. 14-19. [49] Crawford, D. Con trỏ biên tập. Comm. ACM (October, 2001) 5. [50] Cooper, JD, đặc điểm của các Coder Trung bình, thông tin liên lạc cá nhân, tháng năm 1975. [51] Conrow, EH, quản lý rủi ro cho hệ thống của hệ thống, xuyên âm, v. 18, n. 2 (tháng 2 năm 2005), trang 8-12. [52] Cusumano, MA The Factory phần mềm: Một lịch sử Giải thích. IEEE SOFTW. 6, 2 (tháng 3 năm 1989), 23-30