Application VersionEngineering DrawingsAutoCAD 14Euclid 3 1.1HZDHPGL Viewer 4.00DocumentsMS Word 97 SR-1MS Excel 97 SR-1MS Project 98Technical IllustrationsCorelDRAW 6.00Micrografx Designer 7WWW browserNetscape Navigator 4.05On-line copiesAcrobat Distiller 3.0Acrobat Reader 3.0Acrobat Exchange 3.0 up-to-date list see the WWW atwww.cern.ch/CERN/Divisions/EST/LHCQAP/software_versions.htm

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 ModelSystem 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 ModelIt 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.

Waterfall ModelWaterfall 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 ModelReal 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 ModelAgile 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 DocumentationThe 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

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, ExecutablesRequirement 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 beInterviewing 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.