Using the Winwin Spiral Model: a Case Study

Total Page:16

File Type:pdf, Size:1020Kb

Using the Winwin Spiral Model: a Case Study Using the WinWin Spiral Model: A Case Study Computing Practices Fifteen teams used the WinWin spiral model to prototype, plan, specify, and build multimedia applications for USC’s Integrated Library System. The authors report lessons learned from this case study and how they extended the model’s utility and cost-effectiveness in a second round of projects. Barry Boehm t the 1996 and 1997 International Con- Alexander ferences on Software Engineering, three of the six keynote addresses identified Egyed negotiation techniques as the most critical Julie Kwan success factor in improving the outcome Aof software projects. At the USC Center for Software Dan Port Engineering, we have been developing a negotiation- Archita Shah based approach to software system requirements engi- University of neering, architecture, development, and management. Southern Our approach has three primary elements: California • Theory W, a management theory and approach, Ray Madachy which says that making winners of the system’s Litton Data key stakeholders is a necessary and sufficient con- Systems and dition for project success.1 University of • Southern The WinWin spiral model, which extends the spi- California ral software development model by adding Theory W activities to the front of each cycle. The sidebar “Elements of the WinWin Spiral Model” describes The study showed that the WinWin spiral model is these extensions and their goals in more detail. a good match for multimedia applications and is likely • WinWin, a groupware tool that makes it easier to be useful for other applications with similar char- for distributed stakeholders to negotiate mutu- acteristics—rapidly moving technology, many candi- ally satisfactory (win-win) system specifications.2 date approaches, little user or developer experience with similar systems, and the need for rapid comple- In this article, we describe an experimental valida- tion. The study results show that the model has three tion of this approach, focusing on the application of main strengths. the WinWin spiral model. The case study involved extending USC’s Integrated Library System to access • Flexibility. The model let the teams adapt to accom- multimedia archives, including films, maps, and panying risks and uncertainties, such as a rapid pro- videos. The Integrated Library System is a Unix-based, ject schedule and changing team composition. text-oriented, client-server COTS system designed to • Discipline. The modeling framework was suffi- manage the acquisition, cataloging, public access, and ciently formal to maintain focus on achieving circulation of library material. The study’s specific goal three main, or “anchor-point,” milestones: the was to evaluate the feasibility of using the WinWin life-cycle objectives, the life-cycle architecture, and spiral model to build applications written by USC the initial operational capability. (Table A in the graduate student teams. The students developed the sidebar describes these milestones.) applications in concert with USC library clients, who • Trust enhancement. The model provided a means had identified many USC multimedia archives that for growing trust among the project stakeholders, seemed worthy of transformation into digitized, user- enabling them to evolve from adversarial, con- interactive archive management services. tract-oriented system development approaches 0018-9162/98/$10.00 © 1998 IEEE July 1998 33 Elements of the WinWin Spiral Model Since its creation, the spiral model has duce the key product and process objec- been extensively elaborated2 and success- tives, constraints, and alternatives for the The original spiral model1 uses a cyclic fully applied in numerous projects.3,4 next version.6 The model includes a stake- approach to develop increasingly detailed However, some common difficulties led holder WinWin negotiation approach that elaborations of a software system’s defin- USC-CSE and its affiliate organizations to is similar to other team approaches for ition, culminating in incremental releases extend the model to the WinWin spiral software and system definition such as of the system’s operational capability. model described in the main text. gIBIS, Viewpoints, Participatory Design, Each cycle involves four main activities: and Joint Application Design. However, Negotiation front end unlike these and other approaches, we use • Elaborate the system or subsystem’s One difficulty was determining where the stakeholder win-win relationship as the product and process objectives, con- the elaborated objectives, constraints, and success criterion and organizing principle straints, and alternatives. alternatives come from. The WinWin spi- for software and system definition. Our • Evaluate the alternatives with respect ral model resolves this by adding three negotiation guidelines are based on the to the objectives and constraints. activities to the front of each spiral cycle, Harvard Negotiation Project’s techniques.7 Identify and resolve major sources of as Figure A shows.5 product and process risk. Process anchor points • Elaborate the definition of the prod- • Identify the system or subsystem’s key Another difficulty in applying the spiral uct and process. stakeholders. model across an organization’s various pro- • Plan the next cycle, and update the • Identify the stakeholders’ win condi- jects was that the organization has no com- life-cycle plan, including partition of tions for the system or subsystem. mon reference points for organizing its the system into subsystems to be • Negotiate win-win reconciliations of management procedures, cost and schedule addressed in parallel cycles. This can the stakeholders’ win conditions. estimates, and so on. This is because the include a plan to terminate the pro- cycles are risk driven, and each project has ject if it is too risky or infeasible. We have found in experiments with a different risks. In attempting to work out Secure the management’s commit- bootstrap version of the WinWin group- this difficulty with USC-CSE’s industry and ment to proceed as planned. ware tool that these steps do indeed pro- government affiliates using our Cocomo II cost model, we found a set of three process milestones, or anchor points,8 which we 3a. Reconcile win 2. Identify stakeholders' could relate to both the completion of spi- conditions. win conditions. ral cycles and to the organization’s major 3b. Establish next- 1. Identify decision milestones. level objectives, next-level The life-cycle objectives (LCO) and the constraints, and stakeholders. life-cycle architecture (LCA) milestones rat- alternatives. ify the stakeholders’ commitment to a fea- 7. Review and 4. Evaluate product and sible and consistent package of the six key commit. process alternatives. milestone elements shown in Table A for the Resolve risks. LCO anchor point. 6. Validate 5. Define next The LCO version focuses on establishing product level of product a sound business case for the package. It and process and process, need only show that there is at least one fea- definitions. including partitions. sible architecture. The LCA version commits to a single Figure A. How the WinWin spiral model differs from the original spiral model. The new model adds choice of architecture and elaborates it to the front-end activities (blue) that show where objectives, constraints, and alternatives come from. This point of covering all major sources of risk in lets users more clearly identify the rationale involved in negotiating win conditions for the product. the system’s life cycle.8 The LCA is the most toward methods that were mutually supportive MODEL APPLICATION and cooperative. We applied the WinWin spiral model in four cycles: From lessons learned during the case study, we iden- • Cycle 0. Determine the feasibility of an appro- tified several possible enhancements, some of which priate family of multimedia applications. we made. We then used the enhanced model on 16 • Cycle 1. Develop life-cycle objectives (LCO mile- projects in the following year. The second-year pro- stone), prototypes, plans, and specifications for indi- jects overcame many of the weaknesses in the first- vidual applications and verify the existence of at year projects. We are incorporating improvements least one feasible architecture for each application. identified by student critiques and are planning third- • Cycle 2. Establish a specific, detailed life-cycle year projects. Industry is also looking at the WinWin architecture (LCA milestone), verify its feasibil- spiral model. Companies such as Rational Inc. have ity, and determine that there are no major risks in already adopted several elements of the WinWin spi- satisfying the plans and specifications. ral model as part of their project management and • Cycle 3. Achieve a workable initial operational product life-cycle processes. capability (IOC milestone) for each project 34 Computer critical milestone in the software system’s life We found that the LCO and LCA mile- 4. T. Frazier and J. Bailey, “The Costs and cycle. As an analogy, it is similar to the commit- stones are highly compatible with the suc- Benefits of Domain-Oriented Software ment you make in getting married (just as LCO cessful architecture review board practice Reuse: Evidence from the STARS Demon- is like getting engaged and IOC like having your pioneered by AT&T and Lucent Technolo- stration Projects,” IDA Paper P-3191, Insti- first child). gies.9 We used board sessions about 20 per- tute for Defense Analyses, Alexandria, Va., The initial operational capability, or IOC, cent of the time in the first-year projects and 1996. anchor point has three key elements:8 100 percent of the time in the second-year 5. B. Boehm and P. Bose, “A Collaborative Spi- projects, with much better results. ral Software Process Model Based on Theory • Software preparation, including both W,” Proc. Int’l Conf. Software Process, IEEE operational and support software with References CS Press, Los Alamitos, Calif., 1994, pp. 59- appropriate commentary and documen- 1. B. Boehm, “A Spiral Model of Software 68. tation; data preparation or conversion; Development and Enhancement,” Computer, 6. B. Boehm et al., “Software Requirements as the necessary licenses and rights for May 1988, pp.
Recommended publications
  • The Timeboxing Process Model for Iterative Software Development
    The Timeboxing Process Model for Iterative Software Development Pankaj Jalote Department of Computer Science and Engineering Indian Institute of Technology Kanpur – 208016; India Aveejeet Palit, Priya Kurien Infosys Technologies Limited Electronics City Bangalore – 561 229; India Contact: [email protected] ABSTRACT In today’s business where speed is of essence, an iterative development approach that allows the functionality to be delivered in parts has become a necessity and an effective way to manage risks. In an iterative process, the development of a software system is done in increments, each increment forming of an iteration and resulting in a working system. A common iterative approach is to decide what should be developed in an iteration and then plan the iteration accordingly. A somewhat different iterative is approach is to time box different iterations. In this approach, the length of an iteration is fixed and what should be developed in an iteration is adjusted to fit the time box. Generally, the time boxed iterations are executed in sequence, with some overlap where feasible. In this paper we propose the timeboxing process model that takes the concept of time boxed iterations further by adding pipelining concepts to it for permitting overlapped execution of different iterations. In the timeboxing process model, each time boxed iteration is divided into equal length stages, each stage having a defined function and resulting in a clear work product that is handed over to the next stage. With this division into stages, pipelining concepts are employed to have multiple time boxes executing concurrently, leading to a reduction in the delivery time for product releases.
    [Show full text]
  • Manuscript Instructions/Template
    INCOSE Working Group Addresses System and Software Interfaces Sarah Sheard, Ph.D. Rita Creel CMU Software Engineering Institute CMU Software Engineering Institute (412) 268-7612 (703) 247-1378 [email protected] [email protected] John Cadigan Joseph Marvin Prime Solutions Group, Inc. Prime Solutions Group, Inc. (623) 853-0829 (623) 853-0829 [email protected] [email protected] Leung Chim Michael E. Pafford Defence Science & Technology Group Johns Hopkins University +61 (0) 8 7389 7908 (301) 935-5280 [email protected] [email protected] Copyright © 2018 by the authors. Published and used by INCOSE with permission. Abstract. In the 21st century, when any sophisticated system has significant software content, it is increasingly critical to articulate and improve the interface between systems engineering and software engineering, i.e., the relationships between systems and software engineering technical and management processes, products, tools, and outcomes. Although systems engineers and software engineers perform similar activities and use similar processes, their primary responsibilities and concerns differ. Systems engineers focus on the global aspects of a system. Their responsibilities span the lifecycle and involve ensuring the various elements of a system—e.g., hardware, software, firmware, engineering environments, and operational environments—work together to deliver capability. Software engineers also have responsibilities that span the lifecycle, but their focus is on activities to ensure the software satisfies software-relevant system requirements and constraints. Software engineers must maintain sufficient knowledge of the non-software elements of the systems that will execute their software, as well as the systems their software must interface with.
    [Show full text]
  • Agile Playbook V2.1—What’S New?
    AGILE P L AY B O OK TABLE OF CONTENTS INTRODUCTION ..........................................................................................................4 Who should use this playbook? ................................................................................6 How should you use this playbook? .........................................................................6 Agile Playbook v2.1—What’s new? ...........................................................................6 How and where can you contribute to this playbook?.............................................7 MEET YOUR GUIDES ...................................................................................................8 AN AGILE DELIVERY MODEL ....................................................................................10 GETTING STARTED.....................................................................................................12 THE PLAYS ...................................................................................................................14 Delivery ......................................................................................................................15 Play: Start with Scrum ...........................................................................................15 Play: Seeing success but need more fexibility? Move on to Scrumban ............17 Play: If you are ready to kick of the training wheels, try Kanban .......................18 Value ......................................................................................................................19
    [Show full text]
  • Descriptive Approach to Software Development Life Cycle Models
    7797 Shaveta Gupta et al./ Elixir Comp. Sci. & Engg. 45 (2012) 7797-7800 Available online at www.elixirpublishers.com (Elixir International Journal) Computer Science and Engineering Elixir Comp. Sci. & Engg. 45 (2012) 7797-7800 Descriptive approach to software development life cycle models Shaveta Gupta and Sanjana Taya Department of Computer Science and Applications, Seth Jai Parkash Mukand Lal Institute of Engineering & Technology, Radaur, Distt. Yamunanagar (135001), Haryana, India. ARTICLE INFO ABSTRACT Article history: The concept of system lifecycle models came into existence that emphasized on the need to Received: 24 January 2012; follow some structured approach towards building new or improved system. Many models Received in revised form: were suggested like waterfall, prototype, rapid application development, V-shaped, top & 17 March 2012; Bottom model etc. In this paper, we approach towards the traditional as well as recent Accepted: 6 April 2012; software development life cycle models. © 2012 Elixir All rights reserved. Keywords Software Development Life Cycle, Phases and Software Development, Life Cycle Models, Traditional Models, Recent Models. Introduction Software Development Life Cycle Models The Software Development Life Cycle (SDLC) is the entire Software Development Life Cycle Model is an abstract process of formal, logical steps taken to develop a software representation of a development process. SDLC models can be product. Within the broader context of Application Lifecycle categorized as: Management (ALM), the SDLC
    [Show full text]
  • Ovum Decision Matrix: Selecting an Application Lifecycle Management and Devops Solution, 2019–20
    Ovum Decision Matrix: Selecting an Application Lifecycle Management and DevOps Solution, 2019–20 Publication Date: 27 Jun 2019 | Product code: INT003-000374 Michael Azoff Ovum Decision Matrix: Selecting an Application Lifecycle Management and DevOps Solution, 2019–20 Summary Catalyst Software lifecycle management (SLM) is the management of software development by taking a lifecycle approach from concept through the management of requirements, testing, coding, deployment, upgrades, maintenance, and final retirement. The market provides tools to support this lifecycle in the form of application lifecycle management (ALM) tools and, with the rise of DevOps, tools that provide DevOps-style release management, orchestration, and automation. This Ovum Decision Matrix (ODM) examines ALM tools that cross over into DevOps to support the full arc of the lifecycle from application/product concept to deployment into production. Ovum view ALM origins and trends The need for taking an SLM approach is best thought of as good practice in the relatively young art of software development. The ALM tools market has evolved to support SLM through the years; at its core is the development methodology or work process, and this has evolved over time, starting with waterfall or linear stage-gate processes and incorporating various innovations such as Tom Gilb's evolutionary delivery, Barry Boehm's spiral model, and Rational's unified process, before Agile and lean swept the board with examples such as Scrum, extreme programming, and Kanban boards post- 2001 (when the Agile Manifesto was created). The integrated ALM suite tools market really took off around 2003 but supported waterfall because Agile was still under the radar.
    [Show full text]
  • A Comparison Between Five Models of Software Engineering
    IJCSI International Journal of Computer Science Issues, Vol. 7, Issue 5, September 2010 94 ISSN (Online): 1694-0814 www.IJCSI.org A Comparison Between Five Models Of Software Engineering Nabil Mohammed Ali Munassar1 and A. Govardhan2 1Ph.D Student of Computer Science & Engineering Jawahrlal Nehru Technological University Kuktapally, Hyderabad- 500 085, Andhra Pradesh, India 2Professor of Computer Science & Engineering Principal JNTUH of Engineering College, Jagityal, Karimnagar (Dt), A.P., India Abstract increased recently which results in the difficulty of This research deals with a vital and important issue in computer enumerating such companies. During the previous four world. It is concerned with the software management processes decades, software has been developed from a tool used for that examine the area of software development through the analyzing information or solving a problem to a product in development models, which are known as software development itself. However, the early programming stages have life cycle. It represents five of the development models namely, created a number of problems turning software an waterfall, Iteration, V-shaped, spiral and Extreme programming. These models have advantages and disadvantages as well. obstacle to software development particularly those Therefore, the main objective of this research is to represent relying on computers. Software consists of documents and different models of software development and make a programs that contain a collection that has been comparison between them to show the features and defects of established to be a part of software engineering each model. procedures. Moreover, the aim of software engineering is Keywords: Software Management Processes, Software to create a suitable work that construct programs of high Development, Development Models, Software Development Life quality.
    [Show full text]
  • Software Development a Practical Approach!
    Software Development A Practical Approach! Hans-Petter Halvorsen https://www.halvorsen.blog https://halvorsen.blog Software Development A Practical Approach! Hans-Petter Halvorsen Software Development A Practical Approach! Hans-Petter Halvorsen Copyright © 2020 ISBN: 978-82-691106-0-9 Publisher Identifier: 978-82-691106 https://halvorsen.blog ii Preface The main goal with this document: • To give you an overview of what software engineering is • To take you beyond programming to engineering software What is Software Development? It is a complex process to develop modern and professional software today. This document tries to give a brief overview of Software Development. This document tries to focus on a practical approach regarding Software Development. So why do we need System Engineering? Here are some key factors: • Understand Customer Requirements o What does the customer needs (because they may not know it!) o Transform Customer requirements into working software • Planning o How do we reach our goals? o Will we finish within deadline? o Resources o What can go wrong? • Implementation o What kind of platforms and architecture should be used? o Split your work into manageable pieces iii • Quality and Performance o Make sure the software fulfills the customers’ needs We will learn how to build good (i.e. high quality) software, which includes: • Requirements Specification • Technical Design • Good User Experience (UX) • Improved Code Quality and Implementation • Testing • System Documentation • User Documentation • etc. You will find additional resources on this web page: http://www.halvorsen.blog/documents/programming/software_engineering/ iv Information about the author: Hans-Petter Halvorsen The author currently works at the University of South-Eastern Norway.
    [Show full text]
  • Balancing Agility and Discipline a Guide for the Perplexed
    Balancing Agility and Discipline A Guide for the Perplexed Written by Barry Boehm & Richard Turner August 2003 Presented by Ben Underwood for EECS810 Fall 2015 Balancing Agility and Discipline, A Guide for the Perplexed: Boehm & Turner 1 Presentation Outline What to Expect • Meet the Authors • Discipline, Agility, and Perplexity • Contrasts and Home Grounds • A Day in the Life • Expanding the Home Grounds: Two Case Studies • Using Risk to Balance Agility and Discipline • Conclusions • Q & A Balancing Agility and Discipline, A Guide for the Perplexed: Boehm & Turner 2 Meet the Authors Barry Boehm • Born 1935 • Educated in Mathematics at Harvard and UCLA • Worked in Programming and Information Sciences in private industry and government • General Dynamics, Rand Corporation, TRW, and DARPA • Currently at the University of Southern California • Professor of Software Engineering • Founding Director of USC’s Center for Systems and Software Engineering Balancing Agility and Discipline, A Guide for the Perplexed: Boehm & Turner 3 Meet the Authors Richard Turner • Born 1954 • Educated in Mathematics, Computer Science, and Engineering Management • Worked in Computer Science, Technology, and Research in private industry and government • FAA, Systems Engineering Research Center, Software Engineering Institute, George Washington University, and more • One of the core authors of CMMI • Currently at Stevens Institute of Technology • Professor in the School of Systems and Enterprises Balancing Agility and Discipline, A Guide for the Perplexed: Boehm &
    [Show full text]
  • Software Defect Reduction Top 10 List
    SOFTWARE MANANGEMENT TWO Current software projects spend about Software 40 to 50 percent of their effort on avoid- able rework. Such rework consists of effort spent fixing software difficulties that could Defect Reduction have been discovered earlier and fixed less expensively or avoided altogether. By implication, then, some effort must con- sist of “unavoidable rework,” an obser- Top 10 List vation that has gained increasing credibility with the growing realization Barry Boehm, University of Southern California that better user-interactive systems result from emergent processes. In such Victor R. Basili, University of Maryland processes, the requirements emerge from prototyping and other multistakeholder- shared learning activities, a departure from traditional reductionist processes that stipulate requirements in advance, ecently, a National Science insight has been a major driver in focus- then reduce them to practice via design Foundation grant enabled us to ing industrial software practice on thor- and coding. Emergent processes indicate establish the Center for Empiri- ough requirements analysis and design, that changes to a system’s definition that R cally Based Software Engineer- on early verification and validation, and make it more cost-effective should not be ing. CeBASE seeks to transform on up-front prototyping and simulation discouraged by classifying them as avoid- software engineering as much as pos- to avoid costly downstream fixes.” able defects. sible from a fad-based practice to an engineering-based practice through deri- vation, organization, and dissemination Software’s complexity and of empirical data on software develop- accelerated development ment and evolution phenomenology. The phrase “as much as possible” reflects the schedules make avoiding defects fact that software development must remain a people-intensive and continu- difficult.
    [Show full text]
  • Software Maintenance Lifecycle Modeling
    Home Software Maintenance Lifecycle Modeling D Vijay Rao, VVS Sarma and NK Srinivasan Department of Computer Science & Automation Indian Institute of Science Bangalore 560 012, India. Abstract Maintenance of legacy systems, representing a massive, long-term business investment, is an important but relatively new research area. A generic, unified lifecycle model (ULM) integrating the product, process and project views of software development and maintenance based on re- entrant lines is proposed. The proposed re-entrant line model represents the software maintenance process in a software organisation. The existing model for software development predicts project metrics such as the development time, cost and product quality for any new project to be taken up by the organization. The routing matrix of the artifacts in the ULM can be modified to derive different types of lifecycle models such as Waterfall, Prototyping, Spiral and Hybrid models. The ULM is modified to depict the complex set of activities associated with software maintenance. Quantitative metrics such as release time of versions, cost, time and effort for maintenance are estimated using this model. 1. Introduction The area of software maintenance has not received adequate attention in the literature because it was considered as a fairly routine activity with no challenge for creative people. Today, when salaries of programmers have become a major part of the data processing budget, the difficulties in software maintenance are slowly becoming apparent. A large proportion of the software products in operation are the so-called ‘legacy systems’ [TrTi95, LLFG97, BMW96, BM97]. Such systems, that typically are the backbone of an organization’s information flow and business, represent a massive, long-term business investment.
    [Show full text]
  • Iterative & Evolutionary
    iterative.fm Page 9 Sunday, July 20, 2003 1:16 PM Chapter 2 ITERATIVE & EVOLUTIONARY Experience is that marvelous thing that enables you to recognize a mistake when you make it again. —F. P. Jones OVERVIEW ❑ Basic practices of iterative and evolutionary methods, including timeboxing and adaptive planning. ❑ A common mistake adopting iterative methods. ❑ Specific iterative and evolutionary methods, including Evo and UP. Iterative and evolutionary development is a foundation not only of history p. 79 modern software methods, but—as the history section of the “Evi- dence” chapter shows—of methods used as far back as the 1960s. Agile methods are a subset of iterative and evolutionary methods. This chapter summarizes key practices: iterative development evolutionary development risk-driven and client-driven evolutionary requirements timeboxing adaptive planning ITERATIVE DEVELOPMENT Iterative development is an approach to building software (or iterative planning tips anything) in which the overall lifecycle is composed of several iter- start on p. 248 ations in sequence. Each iteration is a self-contained mini-project 9 iterative.fm Page 10 Sunday, July 20, 2003 1:16 PM 2 — Iterative & Evolutionary composed of activities such as requirements analysis, design, pro- gramming, and test. The goal for the end of an iteration is an iter- ation release, a stable, integrated and tested partially complete system. To be clear: All the software across all the teams is inte- grated into a release each iteration. Most iteration releases are internal, a baseline primarily for the benefit of the development team—they are not released externally. The final iteration release is the complete product, released to the market or clients.
    [Show full text]
  • SOFTWARE DEVELOPMENT MODELS and THEIR REAL ASPECTS Divya Tanwar Sbs , Vivekananda Institute of Professional Studies, GGSIPU, Delhi
    SOFTWARE DEVELOPMENT MODELS AND THEIR REAL ASPECTS Divya Tanwar Sbs , Vivekananda Institute of Professional Studies, GGSIPU, Delhi ABSTRACT Software development life cycle models are the most integral part when it comes to software development which can fully justify today’s digitally environments with increasing mobile, web, and desktop applications. This research deals with a vital and important issue in information technology with respect to various models used in development. It is concerned with the software management processes that examine the area of software development through the development models, which are known as software development life cycle. It represents five of the development models namely, waterfall, Iteration, prototype and spiral and their real time examples which we can relate in our day to day life. These models are complex and difficult to identify related to real time scenario. Therefore, the main objective of this research is to represent different models of software development and make a comparison between them to show the features and defects of each model. This paper demystifies these concepts so that the SDLC is correctly understood with their real time. Keywords: Iterative Prototyping SDLC, Software development life cycle, Spiral model, Real aspects, Waterfall model I. INTRODUCTION Software development life cycle models are the important part of the Software Engineering which is a discipline whose aim to develop quality software, which is on time, with minimum cost and can satisfy the organization needs. There are basically four main models in SDLC with different characteristics and drawbacks [2] .The most difficult task is to identify the model which suits the organization structure, for this every organization need to know the model and its real time application so the user can relate, understand and find out how its actually working.
    [Show full text]