Ed writes:
Quote
David Smith writes:
>Paul Nichols [TeamB] writes:
>>
>
I'm curious. Now that "it is a mistake" is known, how are they
going to solve the problem.
That's the problem, there is no way to solve the issue, if you do not
properly plan up front. The project scope is blown, time lines become
blurred and meaningless, and the developers are required to work
unreasonable hours rushing trying to take the stench and dissatisfaction
off of the ones who have made bad decisions to start with.
You basically get left with the task of trying to design and redesign as
well as constantly rewrite code as you understand exactly what you are
working with and what the real requirements and expectations were in the
first place. The code gets messy and you are left with spaghetti code
that is refactored and refactored and refactored.
Quote
Also, pardon my ignorance, but what exactly is the 'planning phase'?
What does one plan for? How does one plan? I realize these questions
are probably answered during the academic phase in Computer Science,
but since I am not a Comp.Sci. graduate, I am curious as to how a
person such as I, be able to plan projects.
Well it always depends upon the project you are working on as to how
much planning you need to do, but basically the following paradigm will
work.
Planning Phase:
Step One: Talk with the unit desiring to have the application written.
This could be an internal busines customer or an external entity. Of
course, if you are the person writing an application for at large
distribution, you are the customer. Write these requirements down, and
reiterate the requirements as you understand them. Question anything you
are not clear on or about to make sure you understand exactly what the
customer is expecting the application to do and why. Generally I follow
a police investigative technique. What is the technique? Always ask the
following questions,
1. Who (who is it for, who is the intended audience?)
2. What (what you are writing, what does it do, what does it
need to integrate with, what tools/languages/databases,
OSes, App Servers, etc do I need?)
3. Where (where will the application be deployed? Will it be
deployed as a server based application, Client/Server,
on Unix, Linux, Solaris, App Server, etc.)
4. When (When does it need to be in service, When does all of
the functionality need to be put into place, can we separate the
functionality into separate releases?)
5. How (How do I go about developing this app. What
languages/tools/databases do we need to develop for, how
do I integrate with other sources, how do I class this
application, how do I develop and break out
functionality, etc.)
If you ask these questions and are diligent about answering all 5, you
will generally come out with the information you need.
Once you get the answers above, you start the formal design process.
Usually the above answers come in the form of Use Cases, either a Use
Case diagram or some other similar Use Case methodology (like bullet
points or flow charts. With Databases, this will usually consists of an
ERD (Entity Relational Diagram).
Once you have a system of Use Cases in a formal document, share this
with the business users or client(s). Make sure that they understand
what your understanding is and add or modify as they see the initial
requirements that need to be modified. If you are lucky, you will have
Business Analyst or PM that will already scoped this out for you, so you
may or may not be involved in the initial steps per above. However,
usually even if I have a BA or PM that gathers initial requirements
(usually in a Business Requirements Document or BRD), I will usually put
this in Use Cases for my team.
If the business or customers have a specific time they need an
application, you may find that you have to trim the requirements and
employ a phased rollout approach. By this I mean that you set
application priorities where you define what are the must have
functionalities in an initial release, with the understanding that added
functionality will come in subsequent releases.
Once these requirements are well documented and signed off on (very
important, if the customer/business does not sign off, you are inviting
and even encouraging scope creep),you start the process of modeling. How
involved the modeling process is developed, will depend on the
complexity of the application itself.
Usually, I try to create an effective class model, modeling the base
classes first. For more complex parts of the application process, I may
use Sequence, Acitvity, or State diagrams. You do not necessarily have
to go the UML route, but with a good UML tools (like Togethersoft), you
can actually use your model to create the core code, which serves two
purposes.
(1)It is easier to find flaws when writing good models. Using UML for
this design process, you are not wasting effort by using something like
flow charts or even psuedo code (which may be necessary as well for
complex parts), due to the fact that the model can actually be used to
create the actual code itself.
(2) Your model becomes a self documenting core code based. This is
extremely useful for integration of existing code into a new or
extended application.
Once these models are establish, you can start handing it off to your
team. Now they have a good model from which to work from and good
requirements from which to work. This modeling process needs to be
performed, not only from your own application, but from all of the
programs you will be working with or integrating with as well.
For instance, if your application is integrating with an existing
databases, you need to have a working ERD Model. If you are integrating
with Web Services, you need good documentation explaining how these
services are suppose to work and how you call them, what the data types
are, etc Sequence diagrams are great here, but if you do not have
these, at the least some documentation and the XSDs will come in handy.
Once you have undertaken this formal process, you can give a good
picture of how long and how many resources you will need to complete the
program in x hours. You should, during this process, flesh out any
potential problem areas as well. For instance, if the business rules say
that I must calculate taxes using a Web Services for each state and
locale for an Order Entry System, then I should be able to see potential
problems when the locale are overlapping. Take Bristol TN and Bristol VA
as an example. The city actually resides in two states and has two
locales. Taxes could be a problem to calculate unless the locale is
specifically identified and some lookup routine would identify which
Bristol we would be dealing with to calculate taxes. This small detail
might be overlooked in an area where the development is far removed from
these types of scenarios. You could potentially code the application not
taking this into account and only discover at QA, UAT, or Production
that you have missed a major potential problem. Proper design and
discussion would probably have caught this using the Where, When, How,
and Why model of investigation.
Quote
I have a project which has a function in the grand scheme
of things at work. I have the tools to complete this project. I'm
the only person who is developing the said project. What exactly
do I need to plan aside for the typical "which objects should
be developed to handle this"?
Use the investigative methodoloogy method (Who, What, When, Where, and
How) and you should be able to determine the planning process. If you
are writing a brand new application, that does not need to integrate
with any other app. you should still plan, but the planning is not as
critical once you get passed the Use Case stage. However, if your
application is integrating with other applications and back end systems,
you need to get with these groups and determine what type of planning
and documentation would be beneficial to you and to them.
Remember the application you write today will probably need to be
expanded and updated for years. You may not be the one doing the
maintenance years from now or you may indeed be the one who hasn't even
thought about this code for years.
Hope this helps!!