Case study(i)


Published on


Published in: Automotive, Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Case study(i)

  1. 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. 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. 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. 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. 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.