Department
of Computer Science and Automation
Indian Institute
of Science
Bangalore - 560 012
INDIA
|
Department
of Computer Science and Automation
|
|
Quick look of the Contents
Object-Technology per-say
is well known among Organizations and Developers. Organizations that have
successfully made the transition to object technology claim significant
time-to-market reduction. Developers say Object Orientation is a fun way to
develop Software. Even though there is a lot of literature on Object
Technology, rarely we find a mention of costs involved in adapting Object
Technology. An immediate fall out of such situation is that new Organizations
and Managers venturing into Object Technology have no way of knowing the
possible pitfalls in such a transformation. At best they can learn only through
their mistakes. It is precisely this reason, which has motivated the author to
scribe this book.
The author made enough efforts to gather data from several dozens of organizations that are doing Object-Oriented projects. Author makes a powerful statistical analysis document out of the above data collected, which forms the basis for several concepts that author tries emphasize in the book. The tangible reasons for, success or failure, of any Organization¢s effort to implement Object Oriented project, have been clearly brought out by author. The central theme of the book is that, If one wants to be successful, then learn lessons from other people¢s experience.
Primary beneficiaries of this book would be
1. The executive scanning for impact to the organization
2. The manager before starting on a project
3. The manager on a project
4. The project’s technical leader
This is a precise and compact book running about 250 pages. The contents of the book are organized into various chapters, each chapter devoted to one major aspect of project development process in Object oriented way. In this review, a brief summery of some of the major issues discussed in the book are extracted and presented here, chapter wise.
This chapter gives brief introduction to various Object oriented concepts like object, class, inheritance, encapsulation, polymorphism, framework and incremental and iterative development.
This chapter focuses on issues like “what are the possible benefits of adapting Object Technology?”, “What are the costs I have to pay for these benefits?”. The author effectively uses the data collected from real world projects to summarize the answers for the above questions. For the sake of clarity and to drive his point more effectively, The author presents brief summery of 11 projects, which he has surveyed, clearly bringing out the reasons for failure or success of each project. In his answer to the question regarding benefits, the author summarizes, the benefits of developing object oriented software as
|
|
|
|
|
|
|
|
|
|
|
|
The costs may include one to two weeks of training in a new programming language and perhaps an investment in some new CASE tools, etc.
Towards the end of this chapter the author points out some of the Non Object issues to be kept in mind while executing a project.
This chapter deals with Selecting and Setting Up an Object Oriented Project. The best first step towards building successful project is to set up the project well. To achieve this objective, the author points out a few basic issues, which must be addressed. They are
1. Selection of suitable project
2. Establishing its purpose
3. Selection of staff, language and tools for execution of project
4. Evaluation of need for training and advise
5. Legacy issues
The author has discussed at length about each of these issues. A few of the above issues are elaborated here to see exactly what the author intends to say.
Project Suitability addresses the question whether the project is naturally suitable to Object technology or not. The author provides us with a few following thumb rules to know whether the projects naturally suitable to Object Oriented approach.
1. The system will be extended by variations on a theme.
2. Objects Obviously give a significantly simplified programme structure
3. The design relies on memory management features of the Object Oriented language.
Based on purpose of the Project undertaken, the projects can be broadly divided into four categories.
1. SWAT – In this type of project aim is to accomplish something relatively small but particularly difficult.
2. Investigative – In this type of project aim will be to detect the problems you may encounter during implementation of Object Technology and to learn a way of working around them.
3. Production – The purpose of this project is to put the real system into use. It is not an experiment. It must succeed but it should not break the company if it is late.
4. Full Commit – The aim of this project is to move the entire organization over to Objects.
Each of the above projects have a different set of ground rules and each requires a different set of staff skills, which must be kept in mind before proceeding with the project.
Here the author identifies three key individuals in project environment for the successful implementation of the project
1. Executive Sponsor: He/She is responsible for getting the project the “nutrition and support it needs.
2. Project Managers: He/She is responsible for the quality of Communication between the teams.
3. The Technical Leader: He/She is responsible for ensuring that a design is used that both, satisfies requirements and can be built by the team.
The author cautions that absence of any one of the above, could cause almost any project fail.
Having finalized a project for development, the author gives us the various issues one has to address for the implementation of the project. They are methodology, estimate, plan, setting milestones and start design. The author explains in detail in this chapter what is meant by methodology and its related aspects.
Methodology: stated in simple words, methodology is nothing but “how your organization repeatedly produces and delivers system”.
Big-M Methodology: is the collected job description of every one on the project, what they do and how they do.
Little-M Methodology: it is collection of details such as “which drawing notation should be used”, “which the author do you follow”.
The author strongly feels that development of Big-M Methodology is crucial to the success of your organization. A few important elements of this methodology are
1. Roles - These are job descriptions you put into the ads when you need to hire more staff.
2. Skills - These are the skills you expect those people to have when they answer the ads.
3. Techniques - The techniques you expect your staff to use in their work.
4. Tools - Which tools the people use in their jobs, either within a technique or to produce a deliverable according to the standard.
5. Teams and Job assignment - How you group people and assign them to multiple roles.
6. Deliverable - What you want each person or team to hand off to another person or team.
7. Standards - What is permitted and not permitted in the design and in the deliverables. These include notation, project convention, quality concerns etc..
In this chapter author deals with the inevitable corrections you will have to make. Author starts discussing a practical example of a project, which starts dismally and then was turned around. Author points out various issues to be kept in mind, during the above discussion. He also lists out a few important principles to be kept in mind during execution of the project
1. Work in Increments.
2. Keep your eye fixed on delivering the system.
3. Be willing to change anything.
4. Get training, Keep learning.
A few important points to note in this chapter are
1. Author emphasizes the need for Incremental and Iterative modes of Development process and how these should be addressed in a project development scenario.
2. User involvement in the project development process is a must in order to make a successful project. Author minces no words to drive this point home.
3.
Author also talks about possible alteration needed, to the
project teams initially established, during some point of the project and
points out that such mid course correction natural and reasonable.
This chapter is a reflection on the first five chapters. Author wants to make the reader realize, what are the important issues to be kept in mind by the reader, either when reader starts another project himself or when reader is advising somebody who is starting a new project.
Author devotes this chapter exclusively for a discussion on executing large-scale projects. Apart from just being different in size from small projects, the big projects do possess some inherent characteristics, which may not be visible at the small project level. A Couple of them are as under.
1. Project planning and Team Coordination are considerably more important on a large project.
2. The key success and risk factors are much more critical. Perhaps you can get away with breaking the rules on a small project but you will not be able to, on a large project.
In this chapter the author compares a real world project using the vocabulary and issues established in the previous chapters. This helps in getting better over view of the software process development cycle and give direction to the reader in addressing the future problems which might occur during the execution of a project.
Modified by: Sandhya G & Shijesta Victor on 03.11.2003