minor training report

Download Minor Training Report

Post on 25-Nov-2014

257 views

Category:

Documents

0 download

Embed Size (px)

TRANSCRIPT

UNIVERSITY INSTITUTE OF TECHNOLOGY RAJIV GANDHI PROUDYOGIKI VISHWAVIDYALAYA BHOPAL (M. P.)Submitted as Minor Training Report in Partial fulfillment for the award of Graduate Degree in Bachelor of Engineering in Information Technology.

Submitted to: Mrs. Asmita Moghe

Submitted By: Ankit Saxena IT Semester VII (0101IT061004)

DEPARTMENT OF INFORMATION TECHNOLGY UNIVERSITY INSTITUTE OF TECHNOLOGY RAJIV GANDHI PROUDYOGIKI VISHWAVIDYALAYA BHOPAL (M.P) June 2009

CERTIFICATEThis is to certify that the Training Report being submitted by Ankit Saxena, student of the Seventh Semester, Degree in Information Technology has done his work as MINOR TRAINING REPORT for the Partial fulfillment of the degree from RGPV, Bhopal (M.P.) is a record of bonafide work done by him under our supervision.

Prof. Asmita MogheReader Information Technology

Prof. Roopam GuptaHead Information Technology

UIT RGPV Bhopal2|P ag e

UIT RGPV Bhopal

ACKNOWLEDGEMENT

I take the opportunity to express my cordial gratitude and deep sense of indebtedness to my guide Mr Tilak Raj Kapoor for the valuable guidance and inspiration throughout the project duration. I feel Thankful to him for his innovative ideas, which led to successful completion of this training. I feel proud and fortunate to work under such an outstanding mentor in the field of Software Development Life Cycle. He has always welcomed my problem and helped me to clear my doubt. I will always be grateful to him for providing me moral support and sufficient time.

I owe sincere thanks to The HOD, Department of Information Technology, Prof. Roopam Gupta Madam, who gave us this opportunity to go out and explore the real industrial experience.

At the same time, I would like to thank Prof. Asmita Moghe Madam and all other faculty members and all non-teaching staff in Information Technology Department for their valuable co-operation.

Ankit Saxena IT, Sem VII UIT RGPV Bhopal

3|P ag e

Table of Contents

Sr. Contents 1. 2. Software Development Life Cycle Software Development Methodology 2.1 Waterfall Model 2.2 Prototyping 2.3 Spiral Model 2.4 Rapid Application Development 3. 4. 5. 6. 7. 8. 9. Agile Software Development Feature Driven Development Scrum Extreme Programming Adaptive Software Development Rational Unified Process Dynamic System Development Method

Page 5 8 9 11 16 18 19 21 23 24 25 25 26 29

10. References

4|P ag e

1. Software Development Life Cycle

The Systems Development Life Cycle (SDLC), or Software Development Life Cycle in systems engineering and software engineering, is the process of creating or altering systems, and the models and methodologies that people use to develop these systems. System Development Life Cycle (SDLC) is any logical process used by a systems analyst to develop an information system, including requirements, validation, training, and user ownership. Any SDLC should result in a high quality system that meets or exceeds customer expectations, reaches completion within time and cost estimates, works effectively and efficiently in the current and planned Information Technology infrastructure, and is inexpensive to maintain and cost-effective to enhance. Computer systems have become more complex and often (especially with the advent of Service-Oriented Architecture) link multiple traditional systems potentially supplied by different software vendors. SDLC models can be described along a spectrum of agile to iterative to sequential. Agile methodologies, such as XP and Scrum, focus on light-weight processes which allow for rapid changes along the development cycle. Some agile and iterative proponents confuse the term SDLC with sequential or "more traditional" processes; however, SDLC is an umbrella term for all methodologies for the design, implementation, and release of software. Systems Development Life Cycle (SDLC) adheres to important phases that are essential for developers, such as planning, analysis, design, and implementation.

5|P ag e

Some argue that the SDLC no longer applies to models like Agile computing, but it is still a term widely in use in Technology circles. The SDLC practice has advantages in traditional models of software development that lends itself more to a structured environment. The disadvantages to using the SDLC methodology is when there is need for iterative development or (i.e. web development or e-commerce) where stakeholders need to review on a regular basis the software being designed. Instead of viewing SDLC from a strength or weakness perspective, it is far more important to take the best practices from the SDLC model and apply it to whatever may be most appropriate for the software being designed.

6|P ag e

Strength and Weaknesses of SDLC Strengths 1. Control. 2. Monitor Large projects. 3. Detailed steps. 4. Evaluate costs and completion targets. 5. Documentation. 6. Well defined user input. 7. Ease of maintenance. 8. Development and design standards. 9. Tolerates changes in MIS staffing. Weaknesses 1. Increased development time. 2. Increased development cost. 3. Systems must be defined up front. 4. Rigidity. 5. Hard to estimate costs, project overruns. 6. User input is sometimes limited.

7|P ag e

2. Software Development Methodology

A software development methodology refers to the framework that is used to structure, plan, and control the process of developing an information system. A wide variety of such frameworks have evolved over the years, each with its own recognized strengths and weaknesses. One system development methodology is not necessarily suitable for use by all projects. Each of the available methodologies is best suited to specific kinds of projects, based on various technical, organizational, project and team considerations.[1] The framework of a software development methodology consists of:

A software development philosophy, with the approach or approaches of the software development process Multiple tools, models and methods, to assist in the software development process.

These frameworks are often bound to some kind of organization, which further develops, supports the use, and promotes the methodology. The methodology is often documented in some kind of formal documentation. Every software development methodology has more or less its own approach to software development. There is a set of more general approaches, which are developed into several specific methodologies. These approaches are:1. 2. 3. 4.

Waterfall: linear framework type. Prototyping: iterative framework type Spiral: combination linear and iterative framework type Rapid Application Development (RAD): Iterative Framework Type

8|P ag e

2.1 Waterfall modelOverview The waterfall model is a sequential software development process, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design (validation), Construction, Testing and maintenance. The waterfall development model has its origins in the manufacturing and construction industries; highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development. The first formal description of the waterfall model is often cited to be an article published in 1970 by Winston W. Royce (1929 1995), although Royce did not use the term "waterfall" in this article. Royce was presenting this model as an example of a flawed, non-working model (Royce 1970). This is in fact the way the term has generally been used in writing about software development as a way to criticize a commonly used software practice. In Royce's original Waterfall model, the following phases are followed in order: 1. Requirements specification 2. Design 3. Construction (AKA implementation or coding) 4. Integration 5. Testing and debugging (AKA Validation) 6. Installation 7. Maintenance To follow the waterfall model, one proceeds from one phase to the next in a purely sequential manner. For example, one first completes requirements specification, which is set in stone. When the requirements are fully completed, one proceeds to design. The software in question is designed and a blueprint is drawn for implementers (coders) to follow this design should be a plan for implementing the requirements given. When the design is fully completed, an implementation of that design is made by coders. Towards the later stages of this implementation phase, separate software components produced are combined to introduce new functionality and reduced risk through the removal of errors. Thus the waterfall model maintains that one should move to a phase only when its preceding phase is completed and perfected. However, there are various modified waterfall9|P ag e

models (including Royce's final model) that may include slight or major variations upon this process.

Figure 1: Waterfall Model Criticism The waterfall model is argued by many to be a bad idea in practice. This is mainly because of their belief that it is impossible for any non-trivial project to get one phase of a software product's lifecycle perfected, before moving on to the next phases and learning from them. Designers may not be aware of future implementation difficulties when writing a design for an unimplemented software product. That is, it may become clear in the implementation phase that a particular area of program functionality is extraordinarily difficult to implement. If this is the case, it is better to revise the design than to persist in using a design that was made based on faulty predictions and that does not account for the newly discovered problem areas. E

View more >