577 Process Patterns & Quality Management

Slides:



Advertisements
Similar presentations
Software change management
Advertisements

Configuration management
University of Southern California Center for Systems and Software Engineering NDI and Services-Based Software Development Process Supannika Koolmanojwong.
Iterative development and The Unified process
8 Systems Analysis and Design in a Changing World, Fifth Edition.
CBS Development: Guidelines Based on Lessons Learned Betsy Clark Software Metrics Inc. February 7, 2001 Sponsored by the Federal Aviation Administration’s.
Problems with reuse – Increased maintenance costs; lack of tool support; not-invented- here syndrome; creating, maintaining, and using a component library.
This chapter is extracted from Sommerville’s slides. Text book chapter
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
University of Southern California Center for Systems and Software Engineering Rapid-Fielding Software-System Development Supannika Koolmanojwong
TEAM’S STRONG/WEAK POINTS David Wiggins – Remote Student 1.
N By: Md Rezaul Huda Reza n
Thirteenth Lecture Hour 8:30 – 9:20 am, Sunday, September 16 Software Management Disciplines Process Automation (from Part III, Chapter 12 of Royce’ book)
Teaching material for a course in Software Project Management & Software Engineering – part II.
 To explain the importance of software configuration management (CM)  To describe key CM activities namely CM planning, change management, version management.
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 Rapid Fielding Projects in CSCI 577 Supannika Koolmanojwong Barry Boehm CS.
University of Southern California Center for Systems and Software Engineering Project Artifacts in each process model Supannika Koolmanojwong October 09,
University of Southern California Center for Systems and Software Engineering NDI & NCS in CSCI 577 Extended from Jesal Bhuta’s presentation for CSCI577a.
Software Prototyping Rapid software development to validate requirements.
1 Chapter 12 Configuration management This chapter is extracted from Sommerville’s slides. Text book chapter 29 1.
University of Southern California Center for Systems and Software Engineering Rapid Fielding Projects in CSCI 577 Supannika Koolmanojwong.
©Ian Sommerville 2007COTS-based System Engineering Slide 1 COTS-based System Engineering.
LECTURE 5 Nangwonvuma M/ Byansi D. Components, interfaces and integration Infrastructure, Middleware and Platforms Techniques – Data warehouses, extending.
Chapter 25 – Configuration Management 1Chapter 25 Configuration management.
Rekayasa Perangkat Lunak Part-6
Systems Analysis and Design in a Changing World, Fifth Edition
Unit 3 Virtualization.
IF 3507 Manajemen Proyek Perangkat Lunak
Chapter 8 Environments, Alternatives, and Decisions.
Prototyping in the software process
Software Project Configuration Management
Software Prototyping.
IS301 – Software Engineering V:
Requirement Prioritization
Web Application Development
IBM Tivoli Web Site Analyzer Training Document
Chapter 18 Maintaining Information Systems
Software testing
Webparts360: A Low-Code App Development Tool That Enables Non-Programmers to Build Business Solutions for Microsoft Office 365 Quickly, Easily OFFICE 365.
Information Systems Selection
Systems Analysis – ITEC 3155 Evaluating Alternatives for Requirements, Environment, and Implementation.
Design and Implementation
Migrating Oracle Forms Using Oracle Application Express
Rapid Fielding Projects in CSCI 577
Software Prototyping Animating and demonstrating system requirements.
Defining the Activities
Chapter 16 – Software Reuse
Methodologies For Systems Analysis.
Tools of Software Development
Chapter 2 Software Processes
Systems analysis and design, 6th edition Dennis, wixom, and roth
Software life cycle models
CSCI 577b Tasks and Activities
Systems analysis and design, 6th edition Dennis, wixom, and roth
OCD Risk Management CS 577a, Fall 2012 ©USC-CSSE.
Enterprise Program Management Office
CHAPTER 10 METHODOLOGIES FOR CUSTOM SOFTWARE DEVELOPMENT
Quality Management, Peer Review, & Architecture Review Board
Comparison between each special case
Capability Maturity Model
DEN Student Roles In Detail
Software Cost Estimation
Configuration management
Chapter 16 – Software Reuse
Rapid software development
Capability Maturity Model
Manage financial resources to ensure solvency
Agenda The current Windows XP and Windows XP Desktop situation
Presentation transcript:

577 Process Patterns & Quality Management October 4, 2017 ©USC-CSSE

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 Market –Driven, Services- Driven, NDI-Driven @USC CSSE

ICSM Process Patterns Process Pattern Example Architected Agile Business data processing Use Single NDI Small website OR NDI- intensive Supply chain management at least 30% at most 70% CUSTOM CODE AND/OR + Services- Intensive Community Services at least 30% at most 70% CUSTOM CODE AND/OR + @USC CSSE

Different Risk Patterns Yield Different Processes 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 @USC CSSE

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. @USC CSSE

Common NDIs in CSCI577 Application-NDI System-NDI MS office, WordPerfect OCR software Business Works Coldfusion, Dreamweaver System-NDI Language: PHP, C++, Java, Database: MySQL Server: Apache Others: Java Libararies @USC CSSE

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. @USC CSSE

Common NCSs in CSCI577 Web services Content Management System 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 @USC CSSE

Why use NDI/NCS? Trade-off 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 volatility @USC CSSE

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 @USC CSSE

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 constraints @USC CSSE

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 future @USC CSSE

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 @USC CSSE

Selection of NDI/NCS Components Assessment of: Functional Win Conditions capability offered Performance Win Conditions timing & sizing constraints Others cost/training/installation/maintenance/market trend / product line @USC CSSE

NDI, NCS characteristics Platform Independent Yes / No Yes Required Internet Access Common Standard No Option of rejecting next release* Change / upgrade control Client /Server’s site Server’s site End user has the latest version Database Ownership Yes/No * Will you be able to freeze the version you are using? @USC CSSE

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 flexible) @USC CSSE

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 ease. @USC CSSE

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 operating? @USC CSSE

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 development @USC CSSE

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 NDI @USC CSSE

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 releases @USC CSSE

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 projects @USC CSSE

Types of NDI-based systems 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 @USC CSSE

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 @USC CSSE

Quality Management ©USC-CSSE

Objectives of QM To ensure the high quality process in order to deliver high quality products (c) USC-CSSE

Quality Management in 577ab IIV&V Configuration Management Defect Reporting and Tracking Testing Buddy Review Architecture Review Board Core Capability Drive through Design Code Review Document template Sample artifacts (c) USC-CSSE

Quality Guidelines Design Guidelines Coding Guidelines Describe design guidelines on how to improve or maintain modularity, reuse and maintenance How the design will map to the implementation Coding Guidelines Describe how to document the code in such as way that it could easily be communicated to others (c) USC-CSSE

Coding Guidelines C: http://www.gnu.org/prep/standards/standards.html Java: http://geosoft.no/development/javastyle.html Visual Basic: http://msdn.microsoft.com/en-us/library/h63fsef3.aspx (c) USC-CSSE

Quality Guidelines Version Control and History Chronological log of the changes introduced to this unit Implementation Considerations Detailed design and implementation for as-built considerations Unit Verification Unit / integration test Code walkthrough / review / inspection (c) USC-CSSE

Quality Assessment Methods Methods, tools, techniques, processes that can identify the problems Detect and report the problem Measure the quality of the software system Three methods of early defect identification peer review, IIV&V, Automated Analysis (c) USC-CSSE

Peer Review Reviews performed by peers in the development team Can be from Fagan’s inspections to simple buddy checks Peer Review Items Participants / Roles Schedule (c) USC-CSSE

Defect Removal Profiles (c) USC-CSSE