good

1. Brief Intro about Our Project:
Our project aim at building such software that would inculcate all the features necessary to
manage Indian Railways. IR is a viscous system. IR is one of the world's largest railway
networks comprising 115,000 km (71,000 mi) of track over a route of 65,000 km (40,000 mi)
and 7,500 stations. Contemporary techniques & tools used by government are old-schooled &
outdated. It is much complicated & process oriented involving a huge amount of HR.
Our project aims at curbing the cost & personnel & yet maintaining the same or even better
amount of quality. Inculcating all the process in IR is cumbersome yet we are trying to
implement process like payments (salary), land procurement(for laying tracks & new stations),
catering, sanitation, ticket mgmt., & so forth(except staffing). It is a web based project
(personalised for IR) which can be accessed by almost any dept. in IR collapsing the cost &
mgmt. issues.
In a nutshell this software contains almost everything (except staffing & route-rail mgmt as
railway has there personalised S/W for this purpose) that government & staff would need to
run & maintain the system.
Why not conventional models?? :
Conventional models such as the waterfall models aims at designing the whole projects in one
go. These models face many limitations which might be cumbersome to implement in current
development environment. Some of the limitations faced by the waterfall models are;
 Difficulty to follow the sequential flow and iterations in this model are handled
indirectly. These changes can cause confusion as the project proceeds.
 In this model we freeze software and hardware. But as technology changes at a rapid
pace, such freezing is not advisable especially in long-term projects.

Even a small change in any previous stage can cause big problem for subsequent
phases as all phases are dependent on each-other.
 Going back a phase or two can be a costly affair.
Including the 10 conventional software mgmt performance rules:
Even though they say it to be conventional following these practises in S/w development. We
are into tight following these practises in our project. They include;
 Finding & fixing S/w problems at the design phase itself.
 Compressing the schedule by applying the adequate resources.
 Including inspections & walkthrough to phase out errors.
 And so on..
Cost estimation:

2. For such a huge project cost estimation is a great issue. Following conventional models like
COCOMO might create future issue & resulting in loss. We can follow various other
techniques for this purpose. Currently various techniques are in practise like;
Software Lifecycle Management:

This model describes the time and effort required to finish a software project of
specified size.
 QSM SLIM Suite provides the best available estimation tools for estimating software
development cost, time and effort needed to satisfy software requirements and
software metrics to benchmark an organization's project performance against
industry standards.
 Highly configurable to multiple design processes.
 & so on…
COCOMO II:
COCOMO II is really three different models:
The Application Composition Model
Suitable for projects built with modern GUI-builder tools. Based on new Object
Points.
The Early Design Model
You can use this model to get rough estimates of a project's cost and duration before
you've determined its entire architecture. It uses a small set of new Cost Drivers, and
new estimating equations. Based on Unadjusted Function Points or KSLOC.
The Post-Architecture Model
Size a big issue!!! :
As we know this is a vast project containing innumerable SLOC. This could a grave issue in
future development & maintenance. We have put a lot of efforts to shrink the size of the
S/w as much as possible. Techniques used are;
Level 4 Languages:




Use of languages as C#, JAVA (J2SE & J2ME), pearl & so on.
Object oriented model (Including classes & dividing the whole project into modules).
Many pieces of code can be reused & few were already developed & past projects.
Inclusion of commercial components & cost & risk calculators etc.

3. Automation:
Many of the project mgmt. processes were automated using various tools available. To name a
few;
 LIGHTHOUSE(Lighthouse is a bug- and issue-tracking app that tracks timelines and
milestones, integrates with your email client and more.)
 SPRINGLOOPS (Springloops is another subversion browser that integrates project
management. It counts a unique AJAX code browser and Basecamp integration as
among its features.)
 JUMPCHART (Jumpchart is a website planning application that allows you to plan the
navigation of your website by creating, dragging and dropping pages into the plan. You
can also add text and formatting to pages and then export your CSS files and site
map when you’re finished.)

4. Following the Principles:
Architecture First Approach: This stage helps in gathering the requirements, making
viable 7 significant decision in designing, & lifecycle plans & placing the before the
resources are committed.
In our project the requirements were vast & so was the designing. The main issue of
architecture was to hide the complexity & working of other modules & making all the
necessary features available at once.
Iterative Life-cycle process: It helps in finding the errors & risk early.
Following iterative process we have developed a pseudo design or say a prototype of
the project. This helps in predicting many risks, like security breach, to be detected
early.
This process helps to maintain a balance between stakeholders, risks, rework & more.
Component Based Development: As there are 100s of department & building a single
S/w for them all is not viable, the whole application is divided into components or say
modules. This helps in keeping all the process independent & atomised from each
other. Moreover it distributes the load of the system equally.
Change management: Emphasis has been made on managing any future changes on the
system. Concurrent workflows by different teams working on shared artifacts,
necessitates objectively controlled baselines.
Objective quality control: Strict quality controlled is maintained at each iteration to
reduce the number of iterations & to decrease the load of future maintenance.
Phases:
Inception:
Various scopes & limitations of the project were laid down.
Team reviews were taken to resolve any ambiguities.
Cost estimation & scheduling was done.
All feasible alternatives for future risks were jotted down.
Evaluation:
Confiding every stakeholder about cost & schedule.
Understanding the requirements.
Actual expenditure Vs Estimated expenditure.(Calculated)
Elaboration Phase:
Here the actual design of the S/w was made containing all its faces &
prototypes.
Tools & process for the construction phases were elaborated & major
milestones were established.
Predesigned & commercial components were chosen.
Stability of the project was checked & evaluated for any failure.

5. Risk elements jotted in previous phases were addressed & alternatives were
implemented.
Agreement of all stakeholders.
Actual expenditure Vs Estimated expenditure. (Acceptable)
Construction Phase:
All features were binded together & coding procedure began.
Project was evaluated to avoid rework.
Testing was performed at every level.
Customers acceptance testing was taken into point.
Transition testing:
Final testing was performed to find out any errors. System focuses on
regression testing.
Databases were checked for load balancing & stability.
All end-users were trained for the end-product.
A support team was established.
User satisfaction.