University of Southern California Center for Systems and Software Engineering Rapid Fielding Projects in CSCI 577 Supannika Koolmanojwong 09/03/10

University of Southern California Center for Systems and Software Engineering Outline Phases and Milestones in ICSM for CSCI577 Tasks and activities in each phase Process patterns in CSCI577 projects NDI & NCS Process Decision Drivers CSSE2

University of Southern California Center for Systems and Software Engineering ICSM: The Incremental Commitment Spiral Model CSSE3

University of Southern California Center for Systems and Software Engineering The Incremental Commitment Model CSSE Commitment and accountability Incremental growth of system definition and stakeholder commitment Concurrent engineering Risk-based activity levels and milestones Success-critical stakeholder satisficing Iterative development cycles

University of Southern California Center for Systems and Software Engineering ICSM in CSCI577 CSSE5

University of Southern California Center for Systems and Software Engineering CSSE6

University of Southern California Center for Systems and Software Engineering Activities in each phase Take a look at details in ICSM-EPG CSSE7

University of Southern California Center for Systems and Software Engineering Outline Phases and Milestones in ICSM for CSCI577 Tasks and activities in each phase Process patterns in CSCI577 projects NDI & NCS Process Decision Drivers CSSE8

University of Southern California Center for Systems and Software Engineering 4 focused ICSM Common Patterns Process Patterns Use Single Non-Developmental Item (NDI) Agile Architected Agile Formal Methods HW with embedded SW component Indivisible IOC NDI- intensive Hybrid agile/ plan-driven system Multi-owner system of systems Family of systems Brownfield Services- Intensive 9 Market –Driven, Services- Driven, NDI-Driven CSSE Note: More information about other process patterns, in EP-07

University of Southern California Center for Systems and Software Engineering ICSM Process Patterns Process PatternExample 10 Architected AgileBusiness data processing Use Single NDISmall website NDI- intensiveSupply chain management Services- IntensiveCommunity Services CSSE OR AND/OR+ at most 70% CUSTOM CODE AND/OR + at least 30% at most 70% CUSTOM CODE at least 30%

University of Southern California Center for Systems and Software Engineering Different Risk Patterns Yield Different Processes CSSE Architected Agile E.g. Business data processing Use Single NDI E.g. Accounting System NDI-Intensive E.g. Supply Chain Management Services-Intensive E.g. Community Services

University of Southern California Center for Systems and Software Engineering Outline Phases and Milestones in ICSM for CSCI577 Tasks and activities in each phase Process patterns in CSCI577 projects NDI & NCS –Definition –Common examples –Why, When is NDI/ NCS right for you ? –Pros and Cons of NDI, NCS –Differences between NDI/NCS –Lesson learned for NDI, NCS Process Decision Drivers CSSE12

University of Southern California Center for Systems and Software Engineering Definitions of NDI / NCS Non-Developmental Item –an item that is previously developed and available to use. –2 kinds of NDI Application NDI : WordPress, Wiki System NDI: MySQL, Apache –Related terms COTS, GOTS, ROTS, Reuse Code, Reuse library, Customer-furnished package NCS or Net-Centric Services is an online service available to be accessed over the Internet such as Google services, Yahoo services, Google map, Twitter, Ning.com, Gmail, Facebook, Amazon payment, online currency converter and online dictionary. –Net-Centric Services is known as web service, web application, online application, cloud computing, and software-as-a-service. CSSE13

University of Southern California Center for Systems and Software Engineering Common NDIs in CSCI577 Application-NDI –MS office, WordPerfect –OCR software –Business Works –Coldfusion, Dreamweaver System-NDI –Language: PHP, C++, Java, –Database: MySQL –Server: Apache –Others: Java Libararies CSSE14

University of Southern California Center for Systems and Software Engineering Net-Centric Services (NCS) an online service available to be accessed over the internet Net-Centric Services includes –web service, –web application, –online application, and –software-as-a-service. CSSE15

University of Southern California Center for Systems and Software Engineering Common NCSs in CSCI577 Web services –Google Services, Yahoo Services Content Management System –Drupal, Joomla e-learning system –Moodle, ILIAS, KEWL, Sakai, Dokeos Payment Services –Amazon payment, Paypal, Google Checkout Calendar –Google Calendar, liteCalendar, Vcalendar Others –OpenCollection, Jumpy Forum, Facebook, Google Map CSSE16

University of Southern California Center for Systems and Software Engineering Why use NDI/NCS? Change in software development practice over the past 20 years Build system with pre-existing software to reduce development and maintenance costs Involve less development time and lower development cost by taking advantage of existing, market proven, vendor supported products. Could develop a better version yourself or outsource but generally incur more expense and take longer to begin to capitalize on its benefits Trade-off Source code is not available to developers Evolution is not under control of developers Incompatibility, high CSSE1709/03/2010

University of Southern California Center for Systems and Software Engineering Trade-Off’s for Tailoring Tailoring effort can vary significantly depending on NDI/NCS package used –Automated tailoring tools E.g. Microsoft Excel macro recorder Extensive tailoring can cause much rework during NDI refresh cycles –Oracle: “Use our Business Processes” Tailoring effort v/s functionality tradeoff –Minimum tailoring effort to obtain maximum possible functionality –Tailoring “easy to redo” during NDI refresh cycles CSSE18

University of Southern California Center for Systems and Software Engineering When is NDI/NCS right for you (1/2) When they lie at the intersection of the three determinants of feasibility, and do so demonstrably better than could original code: – technical, –economic, –strategic CSSE19

University of Southern California Center for Systems and Software Engineering When is NDI/NCS right for you (2/2) Technical constraint –Ability supply the desired functionality at the required level of reliability Economic constraint –Ability to be incorporated and maintained in the new system within the available budget and schedule Strategic constraint –Ability to meet needs of the system operating environment--including technical, political, and legal considerations--now, and as environment is expected to evolve in the CSSE2009/03/2010

University of Southern California Center for Systems and Software Engineering NDI/NCS is not a “Silver Bullet” However, NDI/NCS is not a “Silver Bullet” –Involving short-term & long-term cost, evolution and associated risks –Requiring different processes w.r.t. new skill, knowledge, and abilities –If not handled well, resulting in difficulties to meet expected economic objectives, even causing tremendous cost and schedule overruns Need for NDI/NCS-Oriented Processes CSSE21

University of Southern California Center for Systems and Software Engineering Selection of NDI/NCS Components Assessment of: Functional Win Conditions capability offered Performance Win Conditions timing & sizing constraints Others cost/training/installation/maintenance/ma rket trend / product CSSE2209/03/2010

University of Southern California Center for Systems and Software Engineering NDI, NCS characteristics CSSE23 CharacteristicsNDINCS Platform IndependentYes / NoYes Required Internet AccessYes / NoYes Common StandardNoYes Option of rejecting next release*YesNo Change / upgrade controlClient /Server’s siteServer’s site End user has the latest versionYes / NoYes Database OwnershipYesYes/No * Will you be able to freeze the version you are using?

University of Southern California Center for Systems and Software Engineering NDI Advantages and Disadvantages AdvantagesDisadvantages Available now, earlier paybackLicensing and procurement delays, Up front license fees Avoids expensive development & maintenance Recurring maintenance fees Predictable license costs & performanceReliability often unknown/ inadequate Rich in functionalityUnnecessary features compromise usability, performance Broadly used, mature technologyFunctionality, efficiency constraints Frequent upgrades often anticipate organization’s needs No control over upgrades/maintenance Dedicated support organizationDependency on vendor Hardware/software independenceIntegration not always trivial; incompatibilities among different COTS Tracks technology trendsSynchronizing multiple-vendor upgrades CSSE24

University of Southern California Center for Systems and Software Engineering NCS Advantages and Disadvantages CSSE25 AdvantagesDisadvantages Common Standard; Easy to be integratedRequires internet access Less (minimal) maintenance required, Server side upgrade/change Users have no control over updates; new version may break the systme Users will always have the latest updates The availability and performance are not always guaranteed Platform IndependentLicensing fees (not all services are free) Wide outreachNeed Flexible requirements Available now for faster turnaround time No control over direction of development Provide general services Reduces the development time, Avoids expensive development cost Database ownership and reliability is an issue of concern. Don’t need to worry about local storageSecurity Issue Thin Layer of Functionality needed at User end Operational demos become a necessity to learn the functionality of the application

University of Southern California Center for Systems and Software Engineering Differences between NDI and NCS (1) Category Non-Developmental Item [ includes open source, customer- furnished software] Net-Centric Services Payment  Non-commercial items usually have no monetary cost  Expensive initial costs, moderate recurring fee, training fee, licensing arrangement- dependent  Not all services are free  Low initial costs, moderate marginal cost, duration depending license Platform  Specific and limited to specific platform / language  Generally supported on a subset of platforms or multiple platforms but with different editions  Platform and language independent  Server and client can work on different platform  Interaction between machines over a network Integration  Generally more tightly coupled  Not very flexible on existing legacy systems when proprietary standard is used  Difficult when platform dependent and different technologies involved  detailed documentation and on-site extensive support  More loosely coupled, Common web standards, flexible to integrate  Requires internet access  Support forums and API documentation available  This integration could be done merely in code, without additional installation of external components CSSE26

University of Southern California Center for Systems and Software Engineering Differences between NDI and NCS (2) Category Non-Developmental Item [ includes open source, customer- furnished software] Net-Centric Services Changes  Able to freeze the version, under user control  Designed for specific use so costly for customization and change  Change on server side doesn’t impact the client side  Major releases once in while  Requires end user intervention to upgrade  Changes are out of developers’ control  Not easy to predict change, cannot avoid upgrade  The end-user has the latest version of the service  Change on server side result in client side, not require user intervention  Minor releases frequently (through patching) Extensions  Only if source is provided and the license permits  Extension delivered to the end-user by the producer and integrated into the end-user system.  Custom extensions may not be portable across COTS or compatible with future releases  Extension is limited to data provided by the web services  In-house extension such as wrapper or mashup  Little control over performance overhead CSSE27

University of Southern California Center for Systems and Software Engineering Differences between NDI and NCS (3) Category Non-Developmental Item [ includes open source, customer-furnished software] Net-Centric Services Evaluation Criteria  Maintenance, extensibility, scalability, reliability, cost, support, usability, dependency, ease of implementation, maintainability, upgrades, size, Access to source and code-escrow considerations  Upfront costs opposed to subscription  Platform compatibility, Feature controllability  Reliability, Availability, Cost, Available Support, Speed, Predicted longevity of the service provider, release cycle, Bandwidth  Recurring costs to use of the service and future functionality offered  Standards compatibility  Feature and data controllability Support Services  Vendor support for integration, training and tailoring/modification sometimes available for a fee  Help topics or FAQs would likely not be updated after installation  Upgrades/Patches and data migration support  Sometimes can be customized for specific user  Upgrade through purchasing new releases, self-install  Support for tailoring/modification, training generally not available  Help topics would generally be frequently updated; self-learning  Usually not customized for specific user  Patching on service provider’s side; mostly does not require installation on client side CSSE28

University of Southern California Center for Systems and Software Engineering Differences between NDI and NCS (4) Category Non-Developmental Item [ includes open source, customer- furnished software] Net-Centric Services Data  Data often stored locally. Backups is the responsibility of the user  Data access is generally fast  Possible variety of proprietary formats, Platform-dependent  May be inflexible for change but more secure  Can process data offline  Data stored on service host’s servers. Backups by the provider. Introduces privacy and data-retention  Data access could be slower since internet based, Process data online  Common XML using web standard protocols  Data from different web services can be used by a single client program CSSE29

University of Southern California Center for Systems and Software Engineering Lessons Learned Using NDI (1/6) Problems with vendors –Vendors promise and don’t deliver –Products don’t work as advertised –Don’t assume a quantity discount, negotiate price upfront Need for flexibility in defining requirements –Distinguish between essential and negotiable requirements. Be flexible where you can. –What we did right - spent 14 out of a total of 22 months iterating between requirements, business processes and the marketplace –If you can bend your requirements, NDI is cheaper. Otherwise you’re better off with custom developed. (Not all projects may be CSSE3009/03/2010

University of Southern California Center for Systems and Software Engineering Lessons Learned Using NDI (2/6) Importance of operational demos –Spend a lot of time in detailed performance demonstrations with real users. –Up-front time is critical. That’s when you have leverage with vendors. Once you buy their product, they are a lot less willing to help out. Assessment of specific attributes –Projects (COCOTS), in the past have expressed regret that they did not spend more time assessing portability, inter-component compatibility, flexibility (of user interface), and installation CSSE3109/03/2010

University of Southern California Center for Systems and Software Engineering Lessons Learned Using NDI (3/6) Life-cycle issues –Supportability of NDI viewed as a major issue for safety-critical systems –Out of service is a critical problem contractor purchased source code and will maintain NDI software –Projects, in past have expressed the view that NDI saved money during development but shifted costs to operational side of the life cycle –On-line software maintenance How do you upgrade systems once they are in place and CSSE3209/03/2010

University of Southern California Center for Systems and Software Engineering Lessons Learned Using NDI (4/6) Life Cycle Issues (Upgrading) –What is an effective strategy for upgrading? Products reach end of life in two years. Freeze and redo the system in 10 years? Incorporate all versions from all vendors whenever they come out? Refresh every 2 years? Refresh a selected set of components every 2 years? –Should have an environment set up so you can load new versions onto the existing configuration and decide whether or not to upgrade. –Look at the entire life cycle realistically - not just CSSE3309/03/2010

University of Southern California Center for Systems and Software Engineering Lessons Learned Using NDI (5/6) NDI integrator experience –Important that they have experience integrating NDI. –Look carefully at their credentials. They will oversell themselves Product maturity –Never use an untried OS –Maturity of the software was very important in NDI selection –If you have a safety-critical system, you don’t want state-of-the-art CSSE3409/03/2010

University of Southern California Center for Systems and Software Engineering Lessons Learned Using NDI (6/6) Training on NDI packages –Significant learning curve Need for technology and market watch to keep up with vendors and technologies Impacts of volatility during development –redo the tailoring with new CSSE3509/03/2010

University of Southern California Center for Systems and Software Engineering NDI Systems Definitions NDI-Intensive Systems –Any system that uses NDI NDI Based Applications –A system for which –At least 30% of the end-user functionality is provided by NDI products and –At least 10% of the project effort is devoted to NDI related activities –The numbers 10% and 30% are approximate behavioral NDI boundaries observed in the USC e-services CSSE3609/03/2010

University of Southern California Center for Systems and Software Engineering Types of NDI-based CSSE37 System with no NDI product System with just a single NDI product % of Capability Requirements Implemented by NDI products 100% 0% 30% NDI Based Applications 09/03/2010

University of Southern California Center for Systems and Software Engineering NDI/NCS based development: Key Concepts Process happens where the effort happens Don’t start with requirements Avoid premature commitments, but have and use a plan Buy information early to reduce risk and rework Prepare for NDI/NCS change Use Bottom up rather than top down approach CSSE38

University of Southern California Center for Systems and Software Engineering Outline Phases and Milestones in ICSM for CSCI577 Tasks and activities in each phase Process patterns in CSCI577 projects NDI & NCS Process Decision Drivers CSSE39

University of Southern California Center for Systems and Software Engineering Process Pattern Decision Driver Decision Criteria Importance Architected Agile Use Single NDI NDI-Intensive Services- Intensive Alternatives More than 30% of features available in NDI/NCS 0 – 12 – 33 – 4 Has a single NDI/NCS that satisfies a complete solution 0 – 142 – 3 Very unique/ inflexible business process 2 – 40 – 1 Life Cycle Need control over upgrade / maintenance 2 – 40 – 1 Rapid Deployment; Faster time to market 0 – – 3 Architecture Critical on compatibility 2 – 43 – 41 – 32 – 4 Internet Connection Independence 0 – 4 0 Need high level of services / performance 0 – 40 – 3 0 – 2 Need high security 2 – – 40 – 2 Asynchronous Communication0 – 4 0 Access Data anywhere 0 – 4 4 Resources Critical mass schedule constraints 0 – 13 – 42 – 32 – 4 Lack of Personnel Capability 0 – 23 – 42 – 42 – 3 Little to no upfront costs (hardware and software) 0 – 22 – 4 3 – 4 Low total cost of ownership0 – 10 – 3 3 – 4 Not-so-powerful local machines1 – 41 – 30 – 43 – 4 40 Note: Decision importance scale varies from project to project Decision Criteria Rating Scale; 0:Very Low; 1:Low; 2: Medium; 3:High; 4:Very High Importance Rating Scale: 1:Low; 2: Medium; 3:High CSSE

University of Southern California Center for Systems and Software Engineering An Example of a team that follows the Architected Agile Process Pattern : Shields For Family Project – Develop various reports for LA city-based Family Housing Project CSSE41 Decision Criteria Importance Architected Agile Alternatives More than 30% of features available in NDI/NCS 11 Has a single NDI/NCS that satisfies a complete solution 10 Very unique/ inflexible business process 22 Life Cycle Need control over upgrade / maintenance 33 Rapid Deployment; Faster time to market 1 1 Architecture Critical on compatibility 3 2 Internet Connection Independence 3 1 Need high level of services / performance 23 Need high security 22 Asynchronous Communication 2 3 Access Data anywhere 3 3 Resources Critical mass schedule constraints 2 1 Lack of Personnel Capability 2 2 Little to no upfront costs (hardware and software) 2 2 Low total cost of ownership 2 3 Not-so-powerful local machines 2 2

University of Southern California Center for Systems and Software Engineering An Example of a team that follows the Architected Agile Process Pattern CSSE42 Architected Agile High importance level Low importance level Use single NDI Project Status NDI-Intensive Services -Intensive

University of Southern California Center for Systems and Software Engineering CSSE43

University of Southern California Center for Systems and Software Engineering NDI/NCS based system development process In OCD Use Architected Agile Process Emphasize on Application NDIs, not System NDIs In FED Use NDI, or Net-Centric Services Process Use NDI-intensive or Net-Centric Services Processes CSSE

University of Southern California Center for Systems and Software Engineering NDI/NCS based system development process CSSE

University of Southern California Center for Systems and Software Engineering NDI/NCS based system development process CSSE

University of Southern California Center for Systems and Software Engineering NDI/NCS based system development process CSSE

University of Southern California Center for Systems and Software Engineering CSSE

University of Southern California Center for Systems and Software Engineering NDI/NCS based system development process CSSE