Showing posts with label Software Engineering. Show all posts
Showing posts with label Software Engineering. Show all posts

Tuesday, March 29, 2011

The Unified Process Construction Phase: Best Practices in Implementing the UP



The Unified Process Construction Phase: Best Practices in Implementing the UP
| 2000-08-26 00:00:00 | | 0 | Software Engineering


Is the Unified Process the be all and end all standard for developing object-oriented component-based software? This book is the second in a four volume series that presents a critical review of the Unified Process. The authors present a survey of the alt

This second volume of a four-book series focuses on the design and implementation skeletal versions of new systems for purposes of testing early in the life cycle for quality control. This series is designed to fill the gap between theory and practice with a software process that goes beyond the UP with details of development and production. Fill the gap between theory and practice! Implement a software process that goes beyond the UP with details of development and production. You get a master's collection of best practices from Software Development magazine experts. This volume focuses on the design and implementation skeletal versions of new systems for purposes of testing early in the life cycle for quality control.

User review
Life Saver
This book is great! As a hotshot developer who now finds himself in the ranks of management, this book is a life saver! It is harder and harder for me to get time to do all the reading I really need to do. This book brings together the articles with substance and then flavors the content with insightful editor review. Thanks for producing this series.

User review
Keeping Me Up to Speed
I appreciate this effort by Ambler & Constantine. It is hard for someone like me who has moved from hotshot developer to `visionary leader` (management) to keep up with all my reading. This series has been a blessing by consolidating the appropriate articles for me read. The contents give me many useful perspectives to consider. Thanks.

User review
This book pulls it all together
This is a great book that is part of a great book series. I wasn't sure that a collection of magazine articles was worth paying for, but this book is far more than that. It helps to put the Construction Phase of the RUP into context and actually goes beyond the vanilla version of the RUP to provide advice that I could actually use.

There was a lot of articles about storing objects in relational databases, an idea that put me off at first, but being on an EJB project right now I discovered that these articles really helped me out.

User review
The RUP would be RIP without this book
This, book, like the others in this series, is great. It goes into detail about an improved version of the lifecycle for the Unified Process, one that actually addresses the real world needs of most companies. Trying to use the RUP on multiple projects? Trying to have a common architecture between them? Worried about reuse across projects? This book covers these topics and more with some of the best articles ever published in Software Development magazine.

Personally, I can't imagine anyone adopting the RUP without first reading this book series. I think it's great that someone has gone to the effort to sort through the best articles written by some of the best minds in this industry. Kudos to Ambler and Constantine for having the courage to stand up and say what many others have been afraid to.

User review
Fills in many of the holes
This book is a collection of articles from Software Development magazine. We put this book together to present an alternate view on some of the best practices of the Unified Process, as well as to fill in some of the holes that have yet to be addressed. This includes the addition of a new phase, Production, as well as two new workflows: operations & support and infrastructure management. We invest the first chapter describing the Construction Phase and what should happen during its workflows (including the new ones) and in the rest of the book present articles, along with some new material, for the key workflows of the phase.

For developers we have articles about frameworks written by Arther Jolin and Gregory Rogers; articles for building components by Bertrand Meyer, Desmond D'Souza, and Bruce Powel Douglass; Class normalization written by myself; user interface design by Susan Fowler; a series about persisting objects in relational databases that I wrote; two articles for writing superior code by Dan Saks; several testing articles written by Martin Fowler, James Bach, and others. Plus there are many more articles that I haven't mentioned.

Project managers will benefit from the surviving a death march project by Ed Yourdon; leadership lessons by Larry Constantine; project management best practices by Karl Wiegers; a collection of reuse articles by Meilir Page-Jones, myself, Steve Adolph, Roland Racko, and others. Once again, I didn't reference all the articles aimed at this audience.

Everyone will learn from the eXtreme Programming (XP) article by Warren Keuffel; the configuration management articles by Clemens Szyperski, Tani Haque, and others; as well as the traceability articles that I wrote.

In all I believe this is a really solid book, one that you should read if you are involved with a project following the Rational Unified Process (RUP). The chapter written about the Infrastructure Management workflow alone is likely worth the price of the book, particularly if your organization is trying to successfully manage several development projects at once.


Download this book!

Free Ebooks Download

Friday, February 18, 2011

Advances in Computers, Volume 72: High Performance Computing



Advances in Computers, Volume 72: High Performance Computing
Marvin Zelkowitz Ph.D. MS BS. | 2008-07-08 00:00:00 | Academic Press | 368 | Software Engineering
This is volume 72 of Advances in Computers, a series that began back in 1960 and is the oldest continuing series chronicling the ever-changing landscape of information technology. Each year three volumes are produced, which present approximately 20 chapters that describe the latest technology in the use of computers today. In this volume 72, we present the current status in the development of a new generation of high-performance computers.

The computer today has become ubiquitous with millions of machines being sold (and discarded) annually. Powerful machines are produced for only a few hundred U.S. dollars, and one of the problems faced by vendors of these machines is that, due to the continuing adherence to Moore's law, where the speed of such machines doubles about every 18 months, we typically have more than enough computer power for our needs for word processing, surfing the web, or playing video games. However, the same cannot be said for applications that require large powerful machines. Applications such as weather and climate prediction, fluid flow for designing new airplanes or automobiles, or nuclear plasma flow require as much computer power as we can provide, and even that is not enough. Today's machines operate at the teraflop level (trillions of floating point operations per second) and this book describes research into the petaflop region (1,015 FLOPS). The six chapters provide an overview of current activities that will provide for the introduction of these machines in the years 2011 through 2015.

Download this book!

Free Ebooks Download

Methodologies and Software Engineering for Agent Systems: The Agent-Oriented Software Engineering Handbook (Multiagent Systems, Artificial Societies, and Simulated Organizations)



Methodologies and Software Engineering for Agent Systems: The Agent-Oriented Software Engineering Handbook (Multiagent Systems, Artificial Societies, and Simulated Organizations)
| 2004-06-30 00:00:00 | | 0 | Software Engineering


With increasing acceptance of agent-based computing, a great deal of new research related to the identification and definition of suitable models, tools, and techniques to support the development of complex Multiagent Systems (MAS) has emerged. This research, generally identified as Agent-Oriented Software Engineering (AOSE), continually proposes new metaphors, new formal modeling approaches and techniques, and new development methodologies and tools. The contributions in Methodologies and Software Engineering for Agent Systems, written by leading international researchers, bring together these diverse research results and proposals. The book is separated into six parts, providing the reader with introductory material, concepts and techniques that already provide results for practical use, and research that is still more investigative in nature: Part I introduces the different facets of AOSE research and clarifies why agent-based approaches are suitable to the development of complex software systems, Part II presents three methodologies-Gaia, Tropos, and MaSE-that have been proposed as general-purpose approaches to guide the development of complex MAS, Part III shows four additional methodologies-ADELFE, MESSAGE, SADDE, and Prometheus-that exhibit appealing characteristics which make them suitable for development of specific classes of MAS, such as adaptive MAS and systems based on intelligent intentional agents, and for development of specific application areas, such as telecommunications and agent marketplaces, Part IV shifts the focus from methodologies to infrastructures and tools. Conceptual tools like the FIPA standard and AUML, plus software infrastructures such as tuple-based ones and JADE, are among the most promising ones available to developers, concentrates on innovative approaches to the engineering of agent-based systems, starting from radically different assumptions and concepts than ones traditionally adopted in software development-those that rely on self-organization principles and on biologically or physically inspired solutions, such as swarm intelligence, amorphous computing, adaptive MAS, and online engineering of open systems, nally, Part VI describes two emerging scenarios that are taking benefits from MAS technologies-the Grid and Ubiquitous Computing. The final chapter of the book delineates a research roadmap in the area of AOSE.


Download this book!

Free Ebooks Download

Saturday, January 29, 2011

Developing Windows Error Messages: Error Messages that Communicate



Developing Windows Error Messages: Error Messages that Communicate
Ben Ezzell | 1998-04-01 00:00:00 | O'Reilly Media | 254 | Software Engineering
Although the computer industry has made enormous advances in the last 25 years, the development of error messages has somehow been left behind. Error messages have only progressed from reporting errors as numerical codes to popping up rather simple text messages. Developing Windows Error Messages focuses on the three important elements of an effective error message: notification, explanation, and solution. This book teaches C, C++, and Visual Basic programmers how to write effective error messages that notify the user of an error, clearly explain the error, and most important, offer a solution. Throughout the book the author uses examples that illustrate incomplete error messages and then describes how to make them more effective. The book also discusses methods for preventing and trapping errors before they occur and tells how to create flexible input and response routines to keep unnecessary errors from happening. The accompanying CD-ROM contains a dynamic link library, ErrorMessage.DLL, that is accessible by VB, C, C++, and MFC programs. This DLL contains routines that, when called by the programmer, will present all error messages in a standard format and provide responses for different levels of errors.
Reviews
I would agree with other comments that this book is more philosophical than technical, but I think that is a good thing. When planning a program the error handling side should be more thoroughly planned, and this book helps with just that. I found much of the book obvious, and could flip through 5 or so pages at a time, but the bits that are not so obvious are worth searching for.

If programs are written using the style of error messages and/or the error message handling process suggested within this book I feel that the user term "User Friendly" (at least in relation to errors) would actually be deserved. For instance, how many times have you come across an error that only has one action that you can take "OK"? Is it okay that the error happened? Is it okay that you can't do what you were trying to do?

Therefore I would say that this book holds much more value to the project manager/project leader/planners than programmers.

Much of what is spoken about is not OS specific (besides a bit of code). It seems that it is directly aimed at Windows 95, which is why there is no talk of NT error logs.

I found the supplied code (2 DLLs) to be a bit old but it was a simple enough to use it as a template and build on them. The dialogs within the sample code are quite user and programmer friendly and did not need altering. Using code I already had, I added database error lookup/logging, screen and system capturing, NT Event Logging, email support and COM Interface within a day. HOWEVER I feel that the supplied code is of little value to any programmer who is not planning on altering the code in some way, so it may not be much use if you don't know C++.
Reviews
Ben's book is well-written and well-edited and provides a number of useful ideas on how to write effective error handlers and error messages in the Windows environment. It's focus may seem strange to nonprogrammers, but programmers appreciate this sort of guidance on details.

However, Ben does repeat some saws or maxims which need to be deconstructed.

One is that at one time, error messages were overly terse because "there was not enough storage" to make them useful.

I find this disingenuous, because the dreamtime to which Ben is referring to is probably the early 1980s. In the early 1980s, I was as a former IBM 1401 programmer (whose first machine ten years prior had 8000 characters of storage) in awe of the possibilities of the primitive disk and tape systems then available.

On the 1401 I had developed a system which used an "overlay" and a supplemental manual procedure to provide a user with fully expounded error messages in English, and by the early 1980s, providing my users with English error messages was not a problem.

The idea that at any time "we are limited by the gear available" is to me a confession that a certain need is not important enough to warrant our time. Basically, the need of users for error messages has always been triaged and continues to be triaged in an unconscious binary opposition between the "serious" and MALE tasks of programming, and the "not serious" FEMALE task of communication. To me the first mistake was to divide these tasks.

Another old saw Ben repeats is that "programmers", in inverse proportion to their skill level or interest in being "programmers" do not like to write, or cannot write.

This saw exists in a logical dependence on an idea from outside programming which is that there is such a thing as a content-free "skill in communication". Although a convenient corporate reification, useful for example in getting rid of racial minorities, women, and older employees on the basis that they are mistreated because of a generalized lack of "communications skills", the very idea that we can speak of communication without discussing content, or for that matter simple morality, is nonsense.

"Poor communicator" may be a true generalization as applied to the actual population of programmers in the United States. However, it is belied by a maxim of hero computer scientist Edsger Dijsktra, which is that programming ability is indicated by command of the language.

To the extent that programmers write overly terse error messages they may actually be, while statistically representative of American programmers considered highly qualified, less well-qualified than they could be.

This is because the only evidence we have that the programmer understands his system is something outside code.

Ben Ezzell himself shows he's qualified by not only writing good examples of error messages but also by being aware of what the user probably needs. He does so as a programmer who can code, and it is a false humility of his to say that programming skill has nothing to do with communications skill.

Managers love to give programmers books such as Who Moved my Cheese? and The Elements of Style, probably because these books rigorously exclude the content of the programmer's work from consideration. This may be useful in some cases but basically it is an attempt to deprofessionalize, for it denies that the programmer has learned anything worthwhile.

The managerial saw is that by definition "mere programmers" do not know enough to communicate with users and require by definition an interface consisting of people who do things like review, or actually compose, error messages. But inside the corporation, resources are allocated by non-market means despite the commitment to the free market, and the practical result is that most corporate employees seek first to avoid blame and are therefore not likely to compose forceful and hard-hitting error messages because in the corporation, the messenger is killed for bad news.

I am not dismissing the need for people to perhaps specialise in technical writing or even the composition of error messages...especially for international systems. It would almost be too much to expect programmers to know multiple human languages. What I don't like is the ideology implicit in saying that we must cultivate a content free communications style. I like Ben's book because it is ABOUT both programming and communicating.

The genuine quality of this book, together with its genuine aporias, indicates a need for a definition, outside corporate hegemony, of programming. This definition is needed because if programming is implicitly defined ONLY as MIS programming, it becomes impossible to develop effective systems for the public good...as evidenced by the real problems government and not for profits have in implementing systems; because of omnipresent cost considerations, many such organizations are forced to use off-the-shelf packages which encapsulate (at a deep level) assumptions valid only for private, for profit businesses in what are called "business rules."

A critical theory would define programming, not just writing error messages or documentation, as writing and not mathematical, while at the same time realizing that many practitioners seriously underestimate the applied mathematics of programming. In the present arrangements in the US, programming is considered mathematical and numerical in some sense, thereby excluding many people who could make a contribution, while in another sense, any form of real mathematics and real logic is excluded at the critical point in the development of many systems, usually when cost constraints can be used to justify hand-waving.

If I understood what Claude Levi-Strauss was talking about in expounding a way to read a myth against its own grain rather than literally, I would be able to conclude that American programming praxis is a form of systematically misreading an Enlightenment myth. This would help me to understand why such genuine talent and ability such as Ben's is on display in books from publishers like O'Reilly whereas in practice error messages STILL confuse genuine end users.
Reviews
The book provides some clues on how errors should be considered. It spends a lot of time describing the current situation in a very verbose style. OK that's fun but not very instructive (I mean, we all know half the messages are stupid, unfounded, incomprehensible, etc.). This beeing said I would recommend the book for the same reason....
Reviews
This book contains very little meat for my taste. I can't believe that, as a book devoted to Windows error messages, it does not even mention the Windows NT Event Log anywhere! I'm returning the book since I can't find much in the book that adds to my experience.

Perhaps new programmers can learn a thing or two from this book such as the three elements of good error messages. But as an experienced developer, I'm totally disappointed with this book and would not recommend it to any of my peers.
Reviews
Great book, it read like a satire. This is the first book I have read dedicated to how to write error messages for a particular OS. I guess when your OS is full of cryptic hogwash, investigation reveals that the OS should be discarded altogether. I see a new usenet group forming: alt.badOS.poor.lowest_common_denominator.

I will keep the book as a paean to Bill Gates. Otherwise an average written book by an otherwise great publisher.

Download this book!

Free Ebooks Download

Saturday, January 15, 2011

Agent-oriented Methodologies



Agent-oriented Methodologies
| 2005-06-28 00:00:00 | | 413 | Software Engineering


Agent-Oriented Methodologies presents, analyzes and compares the most significant methodological approaches currently available for the creation of agent-oriented software systems. The chapters of this book each address the details of one specific agent-oriented methodology, written by the original methodology creators. They highlight the methodology details and also the strengths and motivation. Each chapter also notes any purposeful omissions and weaknesses and each ends with a small case study to exemplify the application of the methodological approach. Agent-Oriented Methodologies offers the use of a method engineering approach based on the OPEN Process Framework (OPF) to bring together these potentially disparate methodological approaches to sustain the methodology developers and researchers use in creating a more holistic approach that will be suitable for adoption by industry software developers.


Download this book!

Free Ebooks Download