Your SlideShare is downloading. ×
  • Like
Software lifecycle model report
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Software lifecycle model report

  • 1,540 views
Published

 

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,540
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
54
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 2012 Classification of Software Projects On the Basis Of Its Features and Then Suggesting Appropriate Life Cycle Model Based on the FeaturesAshutoshSingh Department of Electronics and Computer Engineering10114010 Indian Institute of Technology RoorkeeChirag Pawan Under Guidance of:Dr. Sandeep Kumar GargKothari Kumar10114014 10114031 AshutoshUdit Panesar Vikas Yadav10114044 10114046
  • 2. IntroductionSoftware engineering is the application of a systematic, disciplined, quantifiable approach tothe design, development, operation, and maintenance of software, and the study of theseapproaches, that is, the application of engineering to software. There was no softwareengineering some years back.Softwares were being developed, coded and implementedthrough mere intuition and trial and error approach. Gradually Software Engineering hasevolved from an art and taken the form of an engineering methodology .There are differentapproaches to develop software s by following different paradigms and processes . Work isdivided at coded implemented ,designed and delivered finally.Many different methods havecome up for the development of softwares depending upon the problem size , cost andcomplexity, also called Life Cycle Models. They provide a fixed generic framework that canbe tailored to a specific project. Each model has its advantages as well as disadvantages. Toidentify which model is appropriate for the given project, we classify the project on the basisof its features. Feature is an intentional distinguishing characteristic of a software item. Thendepending upon the features we decide which model is appropriate for the given project. Thefeatures are decided not only by the project which means what to do, it also depends upon thecompany or the workforce doing the project and also on user side needs and requirementslike complete delivery at the end or delivery in stages. Software project classification:Based on the different features of the project or the software being developed ,software projectscan be classified into many classes. To develop quality softwares successfully and systematically,different methodology is followed for different types of projects depending upon their differentfeatures. The different identifiable characteristics of the projects are as listed below:-1. Risk 2. Approximated time3. Size and Cost4. Experience of members5. Stability6. Complexity7. Maintenance Requirements8. Reusability9. User involvement10. Requirement specification11. Changes incorporated12. Resources prediction13. Documentations14. Organization structure
  • 3. Now, there are many Life Cycle Models. Here we have thrown light over some of theprominent models used in the industry V DEVELOPMENT MODELOverviewThe V model is a basic Software Development Model, which is sometimes also referred as anextension of the classical waterfall model.The mai difference being that instead of moving ina linear way the steps are bent upwards after the coding phase to form a V shape , as shownin the diagram at the bottom. In the V model there is a link between the phases present in thetwo arms of the V .But this doesn’t mean that it is not a sequential process. It is a sequentialpath of execution of processes. Each phase must be completed before the next starts. Thehorizontal axis represents time of the completion of the project and the vertical axisrepresents the level of abstraction, coarsest grain abstraction being the uppermost.Testing is emphasized in this model more so than the waterfall model though. The testingprocedures are developed early in the life cycle before any coding is done, during each of thephases preceding implementation. Requirements mark the beginning of the life cycle modeljust like the waterfall model. A test plan is made before starting the project. The test planfocuses on meeting the functionality specified in the requirements gathering. The high-leveldesign phase focuses on system architecture and design.In the low-level design phase, theactual software components are designed, and unit tests are created.Coding takes place in theimplementation phase. As the coding gets completed the path of execution changes directionand now starts moving up the V where the test plans which were made earlier are put intouse. A Generalized diagram of the model is shown below: Project Planning and Requirements– allocate resources Product Requirements and Specification Analysis – complete specification of the software system Architecture or High-Level Design– defines how software functions fulfill the design Detailed Design – develop algorithms for each architectural component Production, operation and maintenance – provide for enhancement and corrections System and acceptance testing –check the entire software system in its environment Integration and Testing – check that modules interconnect correctly Unit testing – check that each module acts as expected
  • 4.  Coding – transform algorithms into software PROTOTYPING MODELJourney of the prototyping :-THROWAWAY PROTOTYPING MODEL
  • 5. With throw-away prototyping prototype for a small portion of the system is developed and thengiven to the end user to test and evaluate. The user provides feedback which can quickly be followedand incorporated into the development of the system. The prototype is then thrown away or discarded.This is very different to the evolutionary approach.There are many situations in which user’s end requirements are not clearly specified. This modelfulfils the objective of validating the requirements are validated and clearly understood. The approachis to construct a quick and dirty partial implementation of the system during or before therequirements phase.Main benefits :Used in making projects that have low risk in such areas as losing budget, schedulepredictability and control, large-system integration problems, or coping with information sclerosis,but high risk in user interface design.Main risks:Use in projects that have low risk in such areas as losing budget, schedule predictabilityand control, large-system integration problems, or coping with information sclerosis, but high risk inuser interface design.Advantages:1. This model significantly reduces the project risks.2.The projects formed through this model have a short life span.Disadvantages:1.The prototype basically does nothing. It is just presentational.2.This model can be employed only for limited purposes.EVOLUTIONARY PROTOTYPING MODELThe idea behind this is that an initial prototype is presented to the user. They provide feedback andsuggestions for improvements. These are acted upon by the developer who then presents a morerefined prototype. The user once more provides feedback. The process is repeated.So at each stage the prototype evolves towards the final system.Hence the term evolutionary prototyping.Advantages:1.This model helps to speed up the delivery of the system .2.This model also allows a lot of user interaction.3. The system meets up to the user requirements.Disadvantages:
  • 6. 1. A problem with evolutionary prototyping is knowing when it is necessary to stop tweaking thesystem and actually finish the development.2. Long term maintenance can be expensive. Use in projects that have low risk in such areas as losing budget, schedule predictability and control,large-system integration problems, or coping with information sclerosis, but high risk in user interfacedesign.EXTREME PROGRAMMINGExtreme programming is very far from difficult ,large or complex projects .ExtremeProgramming, also called XP, is a lightweight method of software development based onprinciples of communication ,simplicity, courage and feedback . XP is designed for smallteams who need to build the software quickly in an environment of rapidly-changingre-quirements . It works by bringing the whole team together in the presence of simplepractices, with required feedback to enable the team to see where they stand and to modifythe practices according to their unique situation.Extreme Programming can be summed up into twelve practises:The Planning ProcessThe XP planning process allows the XP customer to set and define the business valueof desired features, and uses cost estimates provided by the coders to choose what needs to bedone and what not. The effect of XP’s planning process is that it is easy to propell the projectto success.Small ReleasesXP teams put a simple system into production early, and update it frequentlythrough a very short cycle.This is repeated for many iterations.MetaphorXP teams use a common “system of names” and a common system descriptionthat guides development and communication.Simple DesignA program built with XP should be the simplest program and it should meet the currentrequirements.There is not much building for the future”. Instead, the focus ison providing business value. Of course it is necessary to ensure that you have agood design, and in XP this is brought about through “refactoring”, discussedbelow.
  • 7. TestingXP teams focus on validation of the software at all times. Programmers de-velop software by writing tests first, then software that fulfills the requirementsreflected in the tests. Customers provide acceptance tests that enable them tobe certain that the features they need are provided.RefactoringXP teams improve the design of the system throughout the entire development.This is done by keeping the software clean: without duplication, with highcommunication, simple, yet complete.Pair ProgrammingXP programmers write all production code in pairs, two programmers workingtogether at one machine. Pair programming has been shown by many exper-iments to produce better software at similar or lower cost than programmersworking alone.Collective OwnershipAll the code belongs to all the programmers. This lets the team go at full speed,because when something needs changing, it can be changed without delay.Continuous IntegrationXP teams integrate and build the software system many times per day. Thiskeeps all the programmers on the same page, and makes very rapid progress possible.Perhaps surprisingly, integrating more frequently tends to eliminate integrationproblems that persists with teams who integrate less often.40-hour WeekTired programmers make more mistakes. XP teams do not work excessiveovertime, keeping themselves fresh, healthy, and effective.On-site CustomerAn XP project is steered by a dedicated individual who is empowered to de-termine requirements, set priorities, and answer questions as the programmershave them. The effect of being there is that communication improves, with lesshard-copy documentation - often one of the most expensive parts of a softwareproject.Coding StandardFor a team to work effectively in pairs, and to share ownership of all the code,all the programmers need to write the code in the same way, with rules thatmake sure the code communicates clearly.
  • 8. Synchronize and Stabilize lifecycleModel:-This lifecycle model defines an overall approach for managing & developing large-scalesoftware systems.Sync-and-stabilize is a Systems Development Life Cycle methodology in which teams workconcurrently on individual application modules. They frequently synchronize their code withthat of other teams, and debug or “stabilize” their code regularly throughout the developmentprocess. Synch-and-stabilize is Microsofts attempt to scale-up a loosely structured small-team ("hacker") style of product development.  Many small teams (3 - 8 developers per team) work in parallel.  Components will work together if changes are synchronized frequently. o Complete recompilation is done at the end of the day so that developers can check their work. o A defect that breaks the build must be fixed immediately  Features are evolved incrementally with occasional innovations. o Start with a "vision statement". o Select features and establish priority of features with user input. o Continued testing is done during development.  The product is stabilized at 3 or 4 milestone junctures in the project life. o It is done thorough internal and external testing. o Fixes almost all errors detected. o "Zero-bug" release is aimed at the last milestone.The special feature of this model is that the specification is complete only when the product isready. This model has been used extensively by many innovative companies. Some of theexample projects using this software development model are some small scale projects i.e.first version of DOS, Lotus1-2-3, WordPerfect, Word or Excel. This process is also known as"milestone", "daily build", "nightly build", and "zero-defect" process. The overall strategy ofthis model is to quickly introduce products that are "good enough" to capture a mass market,and then further improve the product, selling multiple product versions and upgrades.Advantages of Synchronize-and-stabilize model:-- The periodic system building approach makes way for testing the software for itsfunctionality and performance.- Project monitoring will be easy as there will be intermediate milestones.- The integration problems encountered in large projects using other models are eliminatedusing this model.
  • 9. - Because of intermediate releases, the product can be made rich in feature by incorporatingthe necessary feedback methodology.Disadvantages of Synchronize-and-stabilize model:-- A parallel independent testing team needs to work independently.- The detailed specifications document will be made available only at time of release.- Periodic system builds require a rigorous process to be defined for integration of variousmodules.Overview of Synch-and-Stabilize Development ApproachPlanning Phase:- Vision Statement:- Product and program management use extensive customer input to identify and prioritize product features. Specification Document:- Based on vision statement, program management and development group define feature functionality, architectural issues, and component interdependencies. Schedule and Feature Team Formation:- Based on specification document, program management coordinates schedule and arranges feature teams that each contain approximately 1 program manager, 3-8 developers, and 3-8 testers (who work in parallel 1:1 with developers).Development Phase:- Feature Development in 3-4 sequential subprojects that results in amilestone release. Program managers coordinate evolution of specification. Developersdesign, code, and debug. Testers pair up with developers for continuous testing. Subproject I First 1/3 of features: Most critical features And shared components. Subproject II Second 1/3 of features. Subproject III Final 1/3 of features: Least critical Features.Stabilization Phase: - Comprehensive external and internal testing and final productstabilization. Program managers coordinate OEMs (Original Equipment Manufacturer) andISVs and monitor Customer feedback. Developers perform final debugging and Codestabilization. Testers recreate and isolate errors. Internal Testing: - Thorough testing of complete product within the company. External Testing:- Thorough testing of complete product outside the company by "beta" sites such as OEMs, ISVs, and end-users.
  • 10. Release preparation: - Prepare final release of "golden master" diskettes and documentation for manufacturing.Synch-and-Stabilize Development Phase Breakdown:- Time: Usually 2-4 months per Milestone MILESTONE 1 (frst1/3 features):- Development (Design, Coding, Prototyping) Usability-Lab Daily Builds Private Release Testing Feature Debugging: Feature Integration Code Stabilization (no severe bugs): Buffer time: (20-50%) MILESTONE2 (next 1/3)- Development- Usability Lab Daily Builds Private Release Testing Feature Debugging Feature Integration Code Stabilization Buffer time MILESTONE3 (Last Set)- Development, Usability Daily Builds Private Release Testing Feature Debugging Feature Integration Feature Complete Code Complete Code Stabilization Buffer Time Zero Bug Release Release to Manufacturing
  • 11. FOUNTAIN MODELThe model is created by Henderson-Sellers and Edwards. The Fountain model is a logicalimprovement of the Waterfall model. The steps are still there, in the same sequence, howeverat any step there can be a fallback to an earlier step. Moving through a number of steps andfalling back one or more steps, performed repeatedly, is far more flexible than the Waterfallmodel.The process will have following phases: - Requirements Phase - Object Oriented Analysis Phase - Object Oriented Design Phase - Implementation Phase - Implementation and Integration Phase - MaintenanceAdvantages of Fountain model:- - Do not have to freeze the requirements too soon. - Interaction B/W Design and requirement is more. - Able to start the coding earlier.
  • 12. (Stages in Fountain Model)Analysis:Its basic strengths are that it supports iteration within phases, allows parallelism betweenphases, and it is an incremental development. And its weakness is that it may be degradedinto code-a-bit test-a-bit which requires frequent iterations and refinements.I think that the Fountain Model is a better model to use in the industry. Though it would be abit inappropriate for small projects. It has the flexibility to fall back on any phase if someproblems arise in between any of the previous phases. Also practically the requirements keepon changing quite frequently. Even if there is an error in the understanding of the clientrequirements, those can be easily rectified without much loss of project time for not veryhuge systems. Also a combination of a fountain and a spiral model would be more effectiveas the Spiral model could be used at the beginning in the requirements definition phase tominimize the risks involved in the project. This will also lead to a reuse of the componentsdeveloped in the earlier phases. SPIRAL MODEL
  • 13. The spiral Model includes the iterative nature of the prototyping model and the linear natureof the waterfall model. This approach is ideal for developing software that is revealed invarious versions.In each iteration of the spiral approach, software development process follows the phase-wiselinear approach. At the end of first iteration, the customer evaluates the software and providesthe feedback. Based on the feedback, software development process enters into the nextiteration and subsequently follows the linear approach to implement the feedback suggestedby the customer. The process of iteration continues throughout the life of the software.Spiral Approach Phases1. Customer Communication: Includes understanding the system requirements by continuous communication between the customer and the system analyst.2. Planning: Includes estimating Schedule, cost, and resource for the iteration.3. Risk Analysis: includes identifying, estimating, and monitoring technical and management risks, such as schedule slippage and cost overrun.4. Engineering: Includes requirement gathering and design of the software system.5. Construction and release: Includes coding, testing and deploying software at the customer site and providing user-support documents.6. Customer Evaluation: Includes evaluation of software by the customer and implementing feedback in the next iteration of the software development.Product:
  • 14. An example of the spiral model is the evolution of Microsoft Windows Operating systemfrom Windows 3.1 to windows 2003. We may refer to Microsoft windows 3.1 OperatingSystem as the first iteration in the spiral approach. The product was released and evaluated bythe customers, which include the market large. After getting the feedback from customersabout the windows 3.1, Microsoft planned to develop a new version of windows operatingsystem. Windows’95 was released with the enhancement and graphical flexibility. Similarly,other versions of windows operating system were released.Application:The spiral model is mostly used in large projects. For smaller projects, the concept of agilesoftware development is becoming a viable alternative. The spiral model suit small (up to $3million) software applications and not a complicated ($3 billion) distributed, interoperable,system of systems.Also it is reasonable to use the spiral model in projects where business goals are unstable butthe architecture must be realized well enough to provide high loading and stress ability. Forexample, the Spiral Architecture Driven Development is the spiral based SoftwareDevelopment Life Cycle (SDLC) which shows one possible way how to reduce the risk ofnon-effective architecture with the help of a spiral model in conjunction with the bestpractices from other models.Advantages1. Realism: the model accurately reflects the iterative nature of software development onprojects with unclear requirement.2. Flexible: incoporates the advantages of the waterfall and rapid prototyping methods3. Comprehensive model decreases risk4. Good project visibility.Disadvantages1. Needs technical expertise in risk analysis to really work2. Model is poorly understood by nontechnical management, hence not so widely used3. Complicated model, needs competent professional management. High administrativeoverhead.
  • 15. RAPID APPLICATION DEVELOPMENTRapid application development is a software development methodology that involvesmethods like iterative development and software prototyping. According to Whitten(2004), it is a merger of various structured techniques, especially data-driven InformationEngineering, with prototyping techniques to accelerate software systems development.[1]In rapid application development, structured techniques and prototyping are especially usedto define users requirements and to design the final system. The development process startswith the development of preliminary data models and business process models usingstructured techniques. In the next stage, requirements are verified using prototyping,eventually to refine the data and process models. These stages are repeated iteratively; furtherdevelopment results in "a combined business requirements and technical design statement tobe used for constructing new systems"RAD approaches may entail compromises in functionality and performance in exchange forenabling faster development and facilitating application maintenance.Four phases of RAD
  • 16. 1. Requirements Planning phase – combines elements of the system planning and systems analysis phases of the System Development Life Cycle (SDLC). Users, managers, and IT staff members discuss and agree on business needs, project scope, constraints, and system requirements. It ends when the team agrees on the key issues and obtains management authorization to continue. 2. User design phase – during this phase, users interact with systems analysts and develop models and prototypes that represent all system processes, inputs, and outputs. The RAD groups or subgroups typically use a combination of Joint Application Development (JAD) techniques and CASE tools to translate user needs into working models. User Design is a continuous interactive process that allows users to understand, modify, and eventually approve a working model of the system that meets their needs. 3. Construction phase – focuses on program and application development task similar to the SDLC. In RAD, however, users continue to participate and can still suggest changes or improvements as actual screens or reports are developed. Its tasks are programming and application development, coding, unit-integration and system testing. 4. Cutover phase – resembles the final tasks in the SDLC implementation phase, including data conversion, testing, changeover to the new system, and user training. Compared with traditional methods, the entire process is compressed. As a result, the new system is built, delivered, and placed in operation much sooner. Its tasks are data conversion, full-scale testing, system changeover, user training AGILE MODELAgile is a significant departure from the heavyweight document-driven software developmentmethodologies such as Waterfall model. Agile methodologies embrace iterations. Smallteams work together with stakeholders to define quick prototypes, proof of concepts, or othervisual means to describe the problem to be solved.The team defines the requirements for the iteration, develops the code, and defines and runsintegrated test scripts, and the users verify the results. One specialty of this model is thatverification occurs much earlier in the development process than it would with waterfall,allowing stakeholders to fine-tune requirements while they’re still relatively easy to change.
  • 17. image taken from: cs.utexas.edu/users/downing/papers/Agile2007.pdfTypes of agile software development methodologies :  XP (Xtreme Programming)  Scrum Methodology EXTREME PROGRAMMINGExtreme programming is very far from difficult ,large or complex projects .ExtremeProgramming, also called XP, is a lightweight method of software development based onprinciples of communication ,simplicity, courage and feedback . XP is designed for smallteams who need to build the software quickly in an environment of rapidly-changingre-quirements . It works by bringing the whole team together in the presence of simplepractices, with required feedback to enable the team to see where they stand and to modifythe practices according to their unique situation.Extreme Programming can be summed up into twelve practises:The Planning ProcessThe XP planning process allows the XP customer to set and define the business valueof desired features, and uses cost estimates provided by the coders to choose what needs to bedone and what not. The effect of XP’s planning process is that it is easy to propell the projectto success.
  • 18. Small ReleasesXP teams put a simple system into production early, and update it frequentlythrough a very short cycle.This is repeated for many iterations.MetaphorXP teams use a common “system of names” and a common system descriptionthat guides development and communication.Simple DesignA program built with XP should be the simplest program and it should meet the currentrequirements.There is not much building for the future”. Instead, the focus ison providing business value. Of course it is necessary to ensure that you have agood design, and in XP this is brought about through “refactoring”, discussedbelow.TestingXP teams focus on validation of the software at all times. Programmers de-velop software by writing tests first, then software that fulfills the requirementsreflected in the tests. Customers provide acceptance tests that enable them tobe certain that the features they need are provided.RefactoringXP teams improve the design of the system throughout the entire development.This is done by keeping the software clean: without duplication, with highcommunication, simple, yet complete.Pair ProgrammingXP programmers write all production code in pairs, two programmers workingtogether at one machine. Pair programming has been shown by many exper-iments to produce better software at similar or lower cost than programmersworking alone.Collective OwnershipAll the code belongs to all the programmers. This lets the team go at full speed,because when something needs changing, it can be changed without delay.Continuous IntegrationXP teams integrate and build the software system many times per day. Thiskeeps all the programmers on the same page, and makes very rapid progress possible.Perhaps surprisingly, integrating more frequently tends to eliminate integrationproblems that persists with teams who integrate less often.40-hour Week
  • 19. Tired programmers make more mistakes. XP teams do not work excessiveovertime, keeping themselves fresh, healthy, and effective.On-site CustomerAn XP project is steered by a dedicated individual who is empowered to de-termine requirements, set priorities, and answer questions as the programmershave them. The effect of being there is that communication improves, with lesshard-copy documentation - often one of the most expensive parts of a softwareproject.Coding StandardFor a team to work effectively in pairs, and to share ownership of all the code,all the programmers need to write the code in the same way, with rules thatmake sure the code communicates clearly. SCRUM METHODOLOGY‘Scrum’ (related to “scrimmage”) is the term for a huddled mass of players engaged witheach other to get a job done in rugby. In software development, the job is to put out a release.Scrum for software development came out of the rapid prototyping community because userswanted a methodology that would support an environment in which the requirements werenot only incomplete at the start, but also could change rapidly during development.At the center of each Scrum project, there is a backlog of work to be done. This backlog ispopulated during theplanning phase of a release and defines the scope of the release. After theteam completes the project scope and high-level designs, it divides the development processinto a series of short iterations called sprints.These sprints aim to implement a fixed number of backlog items. Before each sprint, the teammembers identify the backlog items for the sprint. The team reviews the sprint to articulatelessons learned and check progress at the end of sprint.The Scrum development process concentrates on managing sprints. Before each sprintbegins, the team plans the sprint, identifying the backlog items and assigning teams to theseitems. Teams develop, wrap, review, and adjust each of the backlog items. Below is picturedescribing the Scrum method:
  • 20. PROJECT ENVIRONMENT IMPACT ON LIFECYCLE MODEL:-Design and adaptation of the life cycle model for each project category or subcategory mustreflect the important characteristics of the project environment. So life cycle models arecategorized on the basis of Project types as following: Project Categories Life Cycle Models 1. Aerospace/Defense Projects Defense Acquisition Model. 1.1 Defense systems Process Based Mission Assurance (PMBA) 1.2 Space Program Life Cycle model. 1.3 Military operations 2. Business & Organization Change Generic Waterfall, Parallel-Work, Projects Evolutionary Models. 2.1 Acquisition/Merger Standard Waterfall, Cyclical, Spiral Models. 2.2 Management process improvement 2.3 New business venture 2.4 Organization re-structuring 2.5 Legal proceeding 3. Communication Systems Projects -do- 3.1 Network communications systems
  • 21. 3.2 Switching communications systems4. Event Projects -do- 4.1 International events 4.2 National events5. Facilities Projects -do- 5.1 Facility decommissioning 5.2 Facility demolition 5.3 Facility maintenance and modification 5.4 Facility design/procurement/construction6. Information Systems (Software) Predictive (Waterfall, Prototyping, RAD, Projects Incremental Build, Spiral) and Adaptive (ASD, XP, SCRUM) Models. Code and Fix, Incremental, Iterative Model. Formula-IT Development Model. Refined Process Spiral Model.7. International Development Projects Waterfall, Spiral Models. 7.1 Agriculture/rural development 7.2 Education 7.3 Health 7.4 Nutrition 7.5 Population 7.6 Small-scale enterprise8. Media & Entertainment Projects -do- 8.1 Motion picture 8.2 TV segment 8.2 Live play or music event9. Product and Service Development Stage/Gate Product Development Model. Projects Phase-Gate Process Model. 9.1 Information technology hardware Pharmaceutical Model. 9.2 Industrial product/process 9.3 Consumer product/process 9.4 Pharmaceutical product/process 9.5 Service (financial, other)10. Research and Development Projects Technical Acquisition: Basic Model, Phased 10.1 Environmental Model, Multi-Solution Model. 10.2 Industrial 10.3 Economic development 10.4 Medical 10.5 Scientific