Managing Projects with Obsydian

Author:

Nicola Zordan is a consultant with over 10 years experience in the IT industry. He worked with Obsydian at Synon Italy since 1995 as a mentor, speaker and project leader.
He is Italian and in 1997 moved to the USA in San Francisco to work at Axis Consulting International, to start up and lead the Obsydian team.
You can find his resume at: http://www.mclink.it/personal/MC2074/Synon/Obsydian.htm

The Presentation:

1. Slides

   Author's notes http://www.bigfoot.com/~ObsydiaNik

2. A project The goal of the project The data model The functionality expected Standard behavior The application The existing system to enhance The deadline People working on it

   The main point is the GOAL and sometime it can be lost in technical details, we have to stay focused The fundament is the Data Model but it comes into play later when we already know the main scope of the project. It should be Object Oriented. There are techniques to identify objects (cue cards, ...) The functionality can affect the data model even if it is supposed to represent the function flow Standards, everybody do it, Plex is great on this, but do not attempt to abstract more than your skills, you can improve later when you know how to, I saw several cases where people wanted to define standards before knowing how to Get the application running will involve technical skills, network connections where to deploy or generate Often we have to integrate with existing data or functions The DEADLINE is the timing factor, and is what will say if the project is a success or not. Be careful, sometime it can strech a little. Allow time to deal with unexpected problems. A little technical thing can stop you much more than expected. Do not accept an impossible deadline. Developers are people, not simply resources, you cannot replace or add them easily, they make the difference between success and failure

3. People in a project The commissioner Client Division The salesman The project leader Client supervisor Consultant project leader Developers involved On site Client Consultants Remote

   A Project is a request to development to provide a software feature for the business. The salesman, the person that goes out and sells the service, is very important, he makes the deal, he is trusted able to provide the service. He play his reputation. And have to deal with the competition. I guess he should be involved in the phases of the project. The Project Leader is the one that always knows the state of the project. If late, on time, if it can be done. Knows timing and resources requirements. Developers, humans, good, bad, ugly, but normally each has his own strength on something, if you find it you have more chances of success Remotes, by e-mail, ftp, conference-calls. Telecommuting is slowly gaining and still have a long way to go. And Obsydian make it so much possible and easy to do. We should have more projects involving telecommuting

4. Type of projects Internal divisions In house developed for client Client side Client side mixed consultants Geographical distributed development

   Internal: Not many projects are done internally now-days, and unfortunately they are normally underestimated. In house project really deliver, the company did invest on Obsydian and they what to get the results. Outsourcing is great today, the consulting company knows is going to deliver because of the many Obsydian features. Distributed development and specialized applications will use most of the ability of Obsydian to integrate in a complex application, Like specialization by branches or Nationality

5. Critical importance Project leader (Internal and external), not only for paperwork and tracking people activity, it have to get the grip on the project Developers, or developers group (depending on the size of the project, but I don’t normally see huge projects done with Obsydian) Methodology to drive the project

   The Project Manager has the handle and knows what is going to be done, the goal, and the state of the project. He knows if there are enough resources, developers, time, and most of all if there are the right skills to complete it. A project is big when with Obsydian it involves more than 5 developers. The project manager (or an application architect) is deeply involved in the methodology used and will drive the direction for it.

6. The project leader Set up the project organization Developers groups Trace project advance Drive meetings Make project strategic decisions Define how to handle modifications

   The Project Leader does most of the set-up for the project and for the structure of the development team and environment. There are several way to trace the state of completion of a project, I will suggest one. He drives the meetings that will be kept short and focused on a level that involves all the developers, without going into the details of single problems that will be discussed separately. Strategic decision about Requirements, Reuse, Timing need to be made to reuse the object and meet the deadline The PM will define how and who will handle changes, modifications and maintenance

7. The data model Developed in team Give scheduled dependencies Define the scope of responsibility to each developer team Define objects ownership Help analyze user requests and straiten them up

   The Data Model is useful also to define (other that the scope of the project naturally) how to assign responsibilities to the parts of the project. It define strict dependencies, "no bill of materials can be built if the material table is not there yet", we will see about this

8. Different types of developers DB analysts Class specialists (know the Obsydian classes) Constructors (AD) Beginners Remote developers

   Class specialists will be able to define abstract objects to be reused intensively throughout the project. The constructors are specialized in defining the logic The beginners will learn, not only technology wise, and the speed of learning depend on the person and on the skills he already have You will hardly find people belonging only to one of these categories but this helps to see the potential of each developer and understand what he can provide to the project

9. Remote development Developing off-site with Obsydian is easy because of the native support to develop out of the network, it is anyway very important to handle the way to get the work done off site and to allow it to be tested and generated properly. Meet the group at scheduled time Defined boundaries of assignments Set up a communication strategy Geographical network and E-Mail Conference call Set up remote test environment

   I haven’t seen any other development tool that allows remote development as well as Obsydian does with Local Models and multi-platform generation. Naturally to work from far away is harder than being there, but it can be done, and we will be looking in that direction with what Obsydian offers. The communication strategy is very important, we all know sometime how important is to get to know how something is done, and if we cannot get to talk to the right person immediately, it gets very hard. With remote developers the need for a Model Administrator is stronger and the figure gets more importance The biggest problem with remote development and several remote generation sites is being able to keep them up to date, unless developers work on almost completely independent subsystems.

10. Set up developer groups With the RAD methodology you have to split the work by responsibility. It is important to set up groups of developers that will be able to handle a whole part of the project, from the design to the test. In Obsydian this methodology can produce good results, Object oriented tools does not deal very well with the layers of responsibility, instead better results can be achieved if each one are responsible for the objects he creates in whole, not only for the design or for the functions. ... Small groups developers, even singles Figure out special ability of each group Multi skilled team

    RAD, Rapid APPLICATION Development, NO PROTOTYPES This is what Obsydian delivers You don’t create prototypes with Obsydian Avoid the layers of knowledge that prevent the knowledge to completely go through, you always loose some part when telling it to somebody else, end even if not may be the person you are talking to will not understand it all or the importance of a little detail. Do not keep the same skills together in groups. No values are added if you keep skills together. Even if it might seem smart to keep skills together to achieve the goal quicker, your developers will get generally much stronger and learn a lot of in the groups there are different skills and so different approaches to solve the same problem. The groups will be more effective

11. RAD, Rapid Application Development Divide project in parts by responsibility Define a schedule of objects to be created by dependencies. Groups of developer must works on areas of responsibility Define a protocol to request services to other groups, OO. Provide with time-boxed estimation to developers Set up environment since the beginning, avoid late addition of people (this will slow because of learning time). Frequent check on project advance, workshops to share knowledge Do not split responsibility on layers (design, program, …)

    The Data Model will tell you who (which group) will have most of the knowledge and responsibility on the project Developers spend a lot of time trying to understand who did this or that to see how it works, and understand it Give objects responsibilities, INCAPSULATION Object Orientation is all about providing services. An object cannot mess around with the data of another object, I think Development structure should follow the same directive Naming the objects properly will make the difference between understanding what the objects do or leave as in the dark with the need to talk to the owner to be able to understand them. I hate naming conventions, prefixes. With Obsydian we have enough space (characters and scoping) to use the right name for each object

12. Managing RAD Provide time-boxed estimation to developers Set up environment from the beginning; avoid late addition of people Monitor progress frequently, schedule workshops to share knowledge Do not split responsibility on layers (design, program, …)

    To provide timing is the main skill of the Project Manager (it still need to be adjusted to the developer team he leads) Adding people later will require them to spend time to learn how the application is engineered and the others to explain it to them. It is necessary to expand the team if the goals expands, but it must be planned somehow. Weekly meeting, and discussing abstract objects features helps a lot the engineering of the project, and saving time. DO NOT SPLIT RESPONSIBILITY IN LAYERS

13. On going changes to projects specifications With RAD methodology, on going modifications are easier to handle because of the knowledge and responsibility on the subject of the groups When changing an object, the team responsible knows what that implies They can tell whoever else could be affected by the modification Adding objects need a redefinition of the dependencies and reassignment of responsibilities Radical changes to objects, need the project to be reorganized, responsibilities and dependencies Even with this methodology we need to keep on going changes as low as possible

    Trying too hard to avoid a design change, like a database change, will end up in a harder solution to implement and mostly will be harder to maintain data and functions.

14. Project management Create a real way to track the project advancing Set up a dependency schedule, everyone must be aware of it and sort their tasks accordingly. (dependency due to object creation) Track any delay, but do not try to force timing by adding more people at last minute, or switching people frequently, this does not work with RAD that relay on responsibility and understanding of the task, not on a simple to do list

    The Dependency Schedule is what I advise as a way to monitor the progresses, and we will see it The Dependency Schedule will show you that "Billing and Invoicing will not be able to deliver if no Addressing is available" (who will they bill to?) It is a good idea to set up a learning environment after every switch in team people or after a phase delivery.

15. Project set-up Arrange short meetings regularly for discussions, focused on inter group requests Schedule objects availability and track the state of the delivered objects (DB, Server fn., User fn.) Have reference users to test and help in the design, who also must have power to make decisions Define the documentation standard for the application Minimize bureaucracy

    Group communication should fill in the details the inter group meeting will not reach. The users you will talk to need to have the power to ask for a change, otherwise the process of getting what the user need can be cumbersome. It is way easier to document while developing than afterwards. I also saw situation where a special group was dedicated to create the documentation for all the subsystems, and surprisingly they did a great job.

16. The dependency schedule Entities in each layer: Are independent of each other. Rely only on entities on the higher level. The Dependency Schedule Determines the order in which objects have to be built Gives an exact way to track the completion state of the project Optimizes the build and reduces the recompilation overhead You can define a diagram type for the dependency You can also define subject areas for each level to help gen and build

    90% of the planning on what object to generate first will be clear in the Dependency Schedule It also can be useful to see the boundaries of the subsystems

17. Project tracking Levels of the dependency schedule reached Percentage of the current level reached Percentage of entities completed Percentage of the special functionality defined Percentage tested Delay rating per developer group

    The most important for the deadline is the % tested. Even if the knowledge of the development work still to do is given by the completion ratio of the Dependency Schedule The Delay rating needs to be associated with some sort of Task sizing, Group efficiency, and workload

18. Development environment Single developer gen. & build PC AS/400 NT Network to share objects Libraries DLL DB

19. Generation environment Personal Development Test Deployment For remote developers we have to consider the generator differences. I.e. the DB generated on AS/400 may require a change in the remote developer if it uses ODBC because or the virtualization restrictions

20. Group model update Single developers update their objects Conflicts should be administered by the project manager since normally they should not append Implementation name conflicts will occur, the responsibility rule must be applied as usual Backup group model centrally controlled after each update Manage with care object renaming and translations

    The developers need to be RESPONSIBLE for their objects to be efficient Normally conflicts will not occur because no developer should change an object belonging to another (the concept should be extended to groups) Responsibility can be granted by object permissions in Obsydian easily. Implementation name conflict will occur because of the object interrelations. Backing up group models need to be done in a single step, backing up all the group models in the network of GM in the project. Obsydian does not allow GM to be out of sink.

21. Versions and Levels Project versioning for new releases Variants to different platform combinations Changes to a process due to different platform must be handled with a different version or with metacode Obsydian version changes, still require a complete regeneration

    Versioning is a very powerful tool that Obsydian gives us. We should use it a lot. Even if there are some little trouble with authorities and object permissions. I saw so little situations where it has been applied.

22. Network of group models Set up standards on a group model Administer standards Define developer group for the standards maintenance Avoid as much as possible changing standards during the project life, it causes mass regeneration that have to be kept in sink The double definition on standard: to understand it is a standard it have to be done at least 2 times, then recreated in the standard model, until Synon will not allow us to move objects between GM.

    Unfortunately Changes on Standards happens often, especially at the beginning. Is the way we learn. Recognizing a pattern I think is the idiosincrasy of the Object Orientation. Still OO is a powerful tool.

23. Deployment and Test Create a structure that allow developers to access and reuse objects that other people will create. Directories and libraries on AS/400 for development, test, deployment. Set up group model update, do not allow people to modify other people objects, and avoid generating other people objects, share them, lib, … Backup the system, use the network

    The generation of the message file on the AS400 can be an issue, if developers changes or add messages often. It can be helped generating the messages in separate libraries for each developer and merging the file in a common message file. Still for changed message the last generated message file will win and update with older messages the messages that other developers merged before. I hope that Sterling will find a better solution for this

I am a consultant with over 10 years experience in the IT industry and I worked with Obsydian since it was first released in 1995 as a mentor, speaker and project leader.
In 1997 I moved to the USA to work wit Axis to start up and leade the Obsydian team.

Home page
Nicola.Zordan@bigfoot.com