Project Management in GIS – Part IIIa

Hi All:

Ooops.. I got some spare time. Though I plan to dedicate at least 15 mins of my time of writing a post per day but some how I skip this activity due to various reasons (mainly lazy I have many posts on my drafts yet to complete.  OK.

In continuation with Project Management in GIS Part I and Part II.  This posts talks about Software Development Life Cycle in short SDLC.  The project are often divided into (rather grouped)  logic phases , together consititues a cycle.  Each phase has its own importance in the cycle.  Each phase is concluded when the delivarable (document/code etc) is completed. There are many types of SLDC models like i) Water Fall ii)  Rational Unified Process iii) Design-Develop- Deploy

Most of  application development projects are executed using water fall model. Below are the phases of Water Fall model.  This posts elaborates about the each phase given below and outlines other models.

  1. Requirements specification (or User Needs Assessment) [with Project  Estimation and Planning]
  2. Design
  3. Build (Coding)
  4. Integration
  5. Testing and debugging
  6. Installation/Deployment
  7. Maintenance

Requirement Specifications (in short RS) – Here requirements from the client is gathered through different channels like conducting meeting across all stake holders, through email or understanding the existing manual work flow etc.  Mostly person who gathers the requirement may be a business consultant/analyst . He will collect all the requirements for the specific project and passed to technical team. The lead developer/analyst who has to analyze the requirement in detail and come with set of questions on the understanding of the requirements. This will be again discussed with the client and final requirements gets approved. Here the person who is gathering a requirement should understand the domain/technology and functional & performance points.

There are three types of requirements – a) Business Requirements b) Functional Requirements c) Performance Requirements

Analysis – Requirements Analysis should be done with extreme care.  The analytical ability is must for this task. The experience of the person who is doing the task is matters most. Let me give me an example  a req is described like ” Search by Parcel and show the results in a grid” .   How to analyze this requirement.

1. What are the columns of parcel data needs to queried upon.

2. How does the UI of search panel should look?. If the query is on multiple columns , do the user wants to construct his own query builder?.  (If yes, then this very complex functionality)

3. What is approximate data size (or # of records of feature class) – This data helps in design process with respect to performance.

4.  How the search results grid UI look like. Do the results should be displayed in panel and ablity like zoom/pan to each record/all records is required?.

5. Once results are shown, does the user requires sorting of data on the columns? ,  when search results has huge records, does pagination sort of functionality is expected.

6. Do you want to actual database columns or alais names for these tables on result grid? and order of columns to be displayed. # of records to be displayed per page ?

7.  Does the resizing of search results panel is required.

8.  What should happen when search results panel is closed, do we need to clear the records?

9. General flow of search functionality.Here, where other map interactions are allowed when the search is in progress?

10. What is performance considerations, what is expected time for search results by the user?

11. Do you require export to excel option on the same search result panel?

Above are questions which came to my mind and each one has its own significance while doing design.  On analysing the requirement to finer level is more important in understanding thec customer expectations. There are many requirements which will be considered as implicit requirement according to client and expect that in a application but it may take considerable or warrants of design change . So the requirements should be captured to finer level and documented with the assumptions.

If some functionality are difficult or technical not possible, we may need to capture those and approved by the client.

The gap between the stated and implicit requirement should be as close to zero.  Its not always possible.

“Walking on  water and working on specifications is easy only when they are frozen” – Unknown 🙂

Let me complete next phases in subsiquent posts. Please provide comments so that I will be aware whether these topics is of interest to audience. Thank you and good night


Tags: ,

2 Responses to “Project Management in GIS – Part IIIa”

  1. pragnesh Says:

    Keep it up!!
    Really interesting.

  2. Jim S Says:

    Thank you for your posts! I would like to read a post on at least the Design phase, if you are able.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: