Object Orientation Challenge in S/W Projects Management & SD

This forum contains all archives from the SD Mailing list (go to http://www.systemdynamics.org/forum/ for more information). This is here as a read-only resource, please post any SD related questions to the SD Discussion forum.
Locked
Saud
Junior Member
Posts: 2
Joined: Fri Mar 29, 2002 3:39 am

Object Orientation Challenge in S/W Projects Management & SD

Post by Saud »

Dear all,

I am a SD student and working on my Master thesis. I would appreciate if
any one give suggestions or references to any existing work to answer
following question:

How Object Orientation can be perceived for S/W Project Management?

Supporting questions to above question can be viewed as:

How reuse of softwares or software components generate benefits for a
company in short term and in long terms?

How encapsulation, polymorphism and other basic OO characteristics can
be better viewed for management of s/w projects and what can be
possible approaches to model these OO characteristics in SD models?

What are the most important measures perceived for project performance
in response to use of OO in analysis, design and coding ?

I feel that object orientation in s/w projects management is a critical
issue and give challenge to SD society due to strong evolution of s/w
tools in these lines and consequently dependence on OO techniques in all
stages of s/w development projects and possible impacts on project
performance. So every one need to say some thing with his/her opinion
how to address this issue in System Dynamics.

Best Regards
Saud
From: Saud <muhammad@ifi.uib.no>
Alex.Rodrigues@dsi.uminho.pt (Al
Junior Member
Posts: 4
Joined: Fri Mar 29, 2002 3:39 am

Object Orientation Challenge in S/W Projects Management & SD

Post by Alex.Rodrigues@dsi.uminho.pt (Al »

Saud, here are some thoughts on your query.

An SD model of a software project captures various processes like: (i) =
the management process of monitoring and re-planning, (ii) human =
resource management, and (iii) the engineering process of software =
development. The use of the OO software engineering paradigm will =
primarily impact on the later -- of course, there can also be indirect =
impacts on management policies.

The are various models for the conventional paradigm of software =
engineering: waterfall, classic life-cycle of phases and activities, =
prototyping, incremental development, RAD, spiral model, and others =
built upon these. Although the use of the OO paradigm can be based on =
one of these models, there are important differences (see Pressman =
1997). This is to say that if OO is employed, the way in which the =
software system is designed, coded and tested will differ. Re-usage of =
objects or even of larger components is likely to take place. On the =
other hand, developing new components using OO will require different =
design, quality control (QC), and testing techniques, than in the =
conventional paradigm.

For an SD model to reflect the use of the OO paradigm, the model =
sub-structure that captures "the way the software is done" (i.e. the =
engineering process of software development) needs to be "OO-tailored". =
When compared against an existing model of conventional development, the =
specific changes will depend on the level of aggregation. There can be =
two types of changes: parametric (including table-functions of effects) =
and structural. The later will impact on the basic feedback structure =
of the model, and are probably more important. However, the more =
aggregated is the model, the less structural detailed is captured , and =
hence the less scope there is for structural readjustments. Ideally, SD =
generic structures (or molecules) of software design, coding and testing =
should be structurally different for the OO and for the conventional =
approach.

Parametric changes are also important but should be subjected to =
validation -- the level of validation of these parameters will depend on =
the accuracy required for the models results, but yet necessary. For =
example, if the model is a multi-phase model, then the inter-phase =
effects on productivity, defect generation, defect detection and rework =
will certainly differ. The book from Abdel-Hamid and Madnick (1991) =
provides a good example on how this validation process can be carried =
out. The use of industry metrics for the OO paradigm is vital. For =
example, Voas (1998) asserts that OO systems suffer from lower =
"functional observability" and so studies on metrics (Hatton 1998) =
suggest that a C++ program will suffer from a defect generation rate 25% =
higher than C, and that the defects will cost two to three times more =
time to be debugged. Proven metrics like these should be used to =
validate the parameters of an OO SD software model.

Let me know if you wish more detail regarding these and other related =
references.

Regards,

Alexandre Rodrigues

___________________________________
Alexandre J G P Rodrigues

Departamento de Sistemas de Informa=E7=E3o
Escola de Engenharia
Universidade do Minho
4800 Guimar=E3es
Portugal, EU

Department of Information Systems
The School of Engineering
University of Minho
4800 Guimar=E3es
Portugal, EU

Tel.: +351 (0)53 510 149
Fax.: +351 (0)53 510 250
Email: Alex.Rodrigues@dsi.uminho.pt
Web: www.dsi.uminho.pt
LOVITTE@dteenergy.com
Newbie
Posts: 1
Joined: Fri Mar 29, 2002 3:39 am

Object Orientation Challenge in S/W Projects Management & SD

Post by LOVITTE@dteenergy.com »

Saud,

I can recommend two books, as I just finished the authors tutorials at the
OOPSLA 98 conference and found their insights on OO Project Management very
useful:

- "Surviving Object-Oriented Projects : A Managers Guide (Addison-Wesley
Object Technology Series)" Alistair Cockburn, Alistar Cockburn (Editor)
- "Succeeding With Objects : Decision Frameworks for Project Management"
Adele Goldberg, Kenneth Rubin (Contributor)

----------------------------
lovitte@dteenergy.com
ISO Technology, Planning, and Consulting
Locked