1. Application Version
Engineering Drawings
AutoCAD 14
Euclid 3 1.1HZD
HPGL Viewer 4.00
Documents
MS Word 97 SR-1
MS Excel 97 SR-1
MS Project 98
Technical Illustrations
CorelDRAW 6.00
Micrografx Designer 7
WWW browser
Netscape Navigator 4.05
On-line copies
Acrobat Distiller 3.0
Acrobat Reader 3.0
Acrobat Exchange 3.0
up-to-date list see the WWW at
www.cern.ch/CERN/Divisions/EST/LHCQAP/software_versions.htm

2. Incremental Model
The Incremental model combines elements of the linear sequential model with the iterative philosophy
of the prototyping. This model has been explicitly designed to accommodate a product that evolves over
time.
When an incremental model is used, the first increment is often a core product. The core product is
used by the customer or undergoes a detailed review. As a result of use and/or evaluation a plan is
developed for the next increment. The plan addresses the modification to the core product to better
meet the needs of the customer and delivery of additional features and functionality. Software is
constructed in a step-by-step manner. While a software product is being developed, each step adds to
what has already been completed.
Advantages of Incremental Model
System is developed and delivered in increments after establishing an overall architecture.
Requirements and specifications for each increment may be developed.
Users may experiment with delivered increments while others are being developed.
Intended to combine some of the advantages of prototyping but with a more manageable process and
better system structure.
Incremental development is especially useful when staffing us unavailable for a complete
implementation by the business deadline.
Early increments can be implemented with fewer people.
When you encounter a difficult deadline that cannot be changed the incremental model is a good
paradigm to consider.
Spiral - Iterative Model
It is an Iterative model that uses the systematic and formal approaches of the linear model. The idea of
minimizing risks by the use of prototype and other means is the concept underlying the spiral model.
After each iteration, the different aspects like risk and the number of iterations to be completed are
adjusted.
A spiral model is divided into a number of framework activities also called as Task Regions. Typically
there are between three to six task regions – Customer Communication, Planning, Risk Analysis,
Engineering, Construction and Release, Customer Evaluation. Each of the regions is populated by a set of
work tasks called a task set that is adapted to the characteristics of the project. As the evolutionary
process begins the team moves around the spiral in a clockwise direction beginning at the center. The
first circuit around the spiral might result in the development of specifications; subsequent passes
around the spiral might be used to develop a prototype and then progressively more sophisticated
versions of the software. Each pass through the planning region results in adjustments to the project
plan.
This model can be applied to small and large projects with more complex comprehensive and numerous
tasks. It may be difficult to convince the customers that the development process is controllable. Also its
success relies heavily on the success of the risk analysis expertise used. This model is particularly well
suited to the development of object-oriented system.

3. Waterfall Model
Waterfall model is the most well-known model in software development also known as the traditional
software development lifecycle.
The waterfall or the linear sequential model illustrates a sequenced systematic approach, which starts
with analysis and progresses through each stage to testing and maintenance/completion.
Each stage has a set of defined milestones and results, and the progress to another stage does not occur
until these predefined results are accomplished. A review is made at the end of each phase to determine
whether the team can advance to the next. If the review gives a negative result, the team remains in the
same stage until all required is completed successfully.
The waterfall model in software development is best suited to environments with stable product
definition, for example, building a well-defined maintenance release of an existing product or porting an
existing product to a new platform.
Problems with the Waterfall Model
Real projects rarely follow the sequential flow that the model proposes.
Although the linear model can accommodate iteration, it does so indirectly as a result; changes can
cause confusion as the project proceeds.
It is often difficult for the customer to state all requirements explicitly.
A working version of the programs will not be available until late in the project time-span.
A major problem, if un-detected until the working program is reviewed can be disastrous.
Waterfall model forms the basis for other software development lifecycle variations.
Agile Model
Agile software development is a style of software development characterized by an emphasis on people,
communication, working software, and responding to change.
All Agile methodologies engage in an iterative workflow and incremental delivery of working software in
short time-boxed iterations. An iteration is essentially a small release of software. Generally during each
iteration many activities will occur in parallel, such as requirements, coding, and testing. Iterations are
typically a fixed length (although this length varies between the methodologies) and thus are referred to
as time-boxed. The time allocated to each iteration is sometimes referred to as a cycle time.
Project Documentation
The following table shows the documentation available at various stages of software development
lifecyclePHASE DESCRIPTION TEAM / DIVISION OUTPUT
Requirement Analysis Analyze customer requirements and formulate a detailed requirements
document Requirement Capture Team and Project Manager Detailed Requirements
ocument (SRS/FS)
Get Signoff from Client for the requirements document Requirement Capture Team and Project
Manager
Create screens for all the forms and device Screen behavior Development Screen designs
with Simulated Behavior and Work Flow. (Prototypes)
Get Clients Signoff on the screen Requirement Capture Team and Project Manager
Architecture and Design Create a System Architecture and Design document Architect and
Project Manager Design and architecture Document (HLD/LLD)
Planning Project Plan Project Manager Project Plan in Microsoft Project
Planning Documents Project Manager, Project Lead, QAM Risk Analysis, SCM, Change
Control, Deployment, Quality Plan, Test Plan, Test Assets
Development Complete features and Unit test them Development
Alpha Testing – Do integration of various modules and perform Manual Tests on the whole
application Development

4. Quality Assurance Perform Automated Tests as per QA Plan, Test Plan and Test cases devised
Quality Assurance Intermittent Release to Client
Client reports issues to Team Quality Assurance
Rework/Bug fixing and Testing by developers Development
Perform Automated Tests as per QA Plan, Test Plan and Test cases devised Quality
Assurance
Release Software Release with Release document Deployment / Release Team
Release Notes, Source Code, Executables
Requirement Analysis
Gathering requirements is a delicate step that encompasses a full realm of skills, knowledge, and ability.
The person doing requirement analysis or business analyst needs to be
Interviewing subject matter experts and relating needs
Organizing complex information into understandable subject areas
"Translating" technical language into business language and vice versa
Ensuring stakeholder involvement at all levels of involvement
Drafting clear and concise written documentation for users and technicians
Working successfully with multidisciplinary teams
The best results in requirement analysis come when business and IT worked together on defining
requirements with minimum budget and time. We provide an experienced analyst with a right mix of
business and IT perspective.
An experienced analyst knows what questions to ask using effective communication skills and easy-to-
understand modeling techniques. The biggest cause of changing requirements is not asking the right
questions in the beginning. A simple, systematic approach leads the analyst and business users to
discover all the information requirements, business rules and functionality, which results in a complete
and accurate business specification the first time.
We employ method and techniques where by the requirements specifications are better, clearer, and
more complete, and are described in a clear, complete, consistent, unambiguous, and precise way.