LARGE SCALE SOFTWARE DEVELOPMENT

IF3250 PROYEK PERANGKAT LUNAK 4 SKS

Sem I 2013/2014

Large Systems

Here in Syracuse at least two very large software systems have been successfully implemented:

Over The Horizon Radar (OTHR) contained about 3,000,000 lines of code, written mostly in FORTRAN with some C and some assembly language as well. BSY-2 submarine battle management system software is several times larger than OTHR, written mostly in Ada.

A 5 million line system would require something like:

5,000,000lines 1 x =947 person yearsof effort 22lines / day 240days / year

Large Systems (2)

So, to complete the project in 2.5 years would require the services of at least 380 well trained software developers. Two points are almost self evident:

a system this large must be partitioned into many rela-tively small, nearly independent components in order to get it to work it would be much better not to create such a large sys-tem at all, but rather, to build most of it from reused sw components, reserving new code for new requirements.

SW Product Model

Architecture
defines product components and allocates processing to them defines external product behavior

Requirements Specification
describes what constitutes correct operation it is the basis for testing and evaluation

Product Specification
defines an architecture for the system describes software design and implementation specifies a software build process

SW Product Model (2)

Test Plan

defines procedures for unit, integration, validation, qualification, and regression testing qualification test procedures are emphasized verifies design for critical processing, analyzes implementation problems as they arise Code for each component of the product, implemented as software modules. test stub attached to each module, used to establish basic software cycling and nearly correct operation test drivers for unit, integration, and qualification tests

Prototype Code

Product Code

Test Code

Test Report

Large Scale (LS) Software Development

Complexity in Software

High LOC, High amount of Data Acces, High computation elements, etc High Requirements Size, Requirements Changes, conflicting requirements, etc

Complexity in Requirements

Complexity in location differences Complexity in platform differences Complexity in politics

Different rules, policies

Complexity in Resource Allocations

Coordination in LS SW Development

The root cause is work coordination between team developers

intra-

and inter- team coordination

Major factors are

Communication Capacity Cooperation

What should we be aware of?

Software Change Software Configuration Management (SCM) Change Control

Software Change Management

Environment Changes
Computer

Hardware Competition Business Processes External Requirements (Y2k, Euro,) New Standards (XML, MP3, e-Speak,)

All Software Demands Change

Incremental

Development Maintenance (Corrective, Perfective, Adaptive)

Source Control Management

Manage Constant Software Change Improve Debugging Productivity

Trace Defect Reports to Correct Versions of Source Code Understand Change History Reproducibility

Build (Compile) Software Accurately, Repeatably Grow Project Size

Avoid Over-writing and Losing Changes Concurrent Development (Improve TTM) Coordinate Work with Development Policies

Versioning

Revision / Version - Single copy of a source file as it appeared at given point in its change history (checkpoint) File / Element - Complete change history; all versions Branch - Set of successive versions; parallel to other branches Delta - Change from one file version to the next

Version Tree

Multiple File Configuration Management

Variant - File based on another, co-exists with original Derived Object - File automatically generated from source files Change Set - Set of versions across multiple files making up a single logical change (e.g., feature or fix) Baseline - Consistent set of versions across all files

Baseline
fubar.c foo.c bar.c

Coordinating Work
Problem: Multiple people working on same file at the same time can result in lost work. Solution 1: Serialize work with file locking. Solution 2: Work in isolation (branch) and merge. Branching and merging scales much better. Merging can be semi-automated using 3-way merge algorithms.

Merging - Version Tree

0

Common Ancestor
1

Merge Result

1 3

Conflicting Changes

Formal definition (IEEE)

SCM is the process of identifying and defining the items in the system, controlling the change of these items throughout their life cycle, recording and reporting the status of items and change requests and verifying the completeness and correctness of the items.

Related Terms: Source Control, Version Control

Managing Change
Change Control - Formal processes for tracking and approval of software modifications. Managed with SCM and defect tracking tools. Usual Policy Areas: Documentation - Change request / defect report filed. Approval - Change request reviewed by release management or technical board. Quality Requirements - Code reviewed, regression tests passed. Policies often change by release stage and in response to problems.

Development Process
Key Components of Development Process: Software Configuration Management Change Control Quality Control

Principles of Large-Scale Software Development

Reproducibility Policy Enforcement versus Policy Auditing Process, Process, Process

A process must be defined to be improved

Automation
A process must be automated to be repeatable

Continuous Functional Integration and Test

Software Integration
Integration: Combining multiple features or components developed in isolation. Large projects are subject to constant change, so isolation on a stable base is necessary. Continuous Functional Integration and Test (CFIT)

Changes integrated throughout development. Changes not allowed to regress functionality or quality.

HP-UX Development

220,000+ Source Files ~2.5 Million Versions 52,000+ Derived Files (Single Nightly Build) 900+ User Accounts More Than 1 Terabyte of Disk Space

HP-UX Concurrent Development

Normally 2-3 Releases Under Development Several Releases Under Maintenance Heavy Use of Branching and Merging

HP-UX Multisite Development

Four Primary Development Sites

Three

in USA (Three Time Zones) One in India

One USA Site Hosts Three Logical Sites

Partner

Companies

Several Secondary Sites

Tiered Software Integration Model

1. Developer Task - Edit, Compile, Test 2. Submit - Batch Changes, Acceptance Test 3. Baseline - Nightly Build, Regression Test 4. Integration - Monthly Packaging, Partner Test 5. Release - Semi-annual Delivery, Production Use

Integration Levels
Release

Integration Cycle Baseline Submit Build Modifications

Process Evolution

Continuous Process Improvement Root Cause Analysis (RCA) Capability Maturity Model (CMM)
1. Initial 2. Repeatable 3. Defined 4. Managed 5. Optimizing

Tools

UML-supported CASE tools

Commercial (license cost per concurrent user, approx 2-6K each)

Rational/IBM XDE Java Edition 2002/XDE .NET Edition 2002 Borlands Together (acquired TogetherSoft) Telelogics System Architect 10 (acquired Popkin Software) Microsofts Enterprise Architect 2002 Ilogixs Rhapsody Gentlewares Poseidon for UML Tigris ArgoUML (Open Source) EclipseUML (Open Source) StarUML (Open Source)

Free

System Architect 10
Telelogic (acquired Popkin Software in 2005) Types of modelling supported: Business Process Modelling Object/Component Modelling Data Modelling Structured Analysis and Design Interface: Drawing Workspace Browser - hierarchical navigation (of diagrams and definitions) Definition dialogues Matrix Editor Import/Export Formats Comma Separated Vale (csv), XML

System Architect 10
Reporting: Proprietary, MS Word templates, HTML Generation Object Modelling UML and old methods (Booch, OMT, etc.) Code Generation C++ (+ reverse engineering), Java (+ reverse engineering), Visual Basic, CORBA IDL, Javascript Schema Generation Data Defintion Language of SQL, e.g. Access, ORacle, etc. GUI screen painter

Together

comprehensive, multi-language modeling platform for software practitioners who design, develop, and/or communicate software architectures Two versions Together 2006 Release 2 for Eclipse (3.2) and Together 2006 for Visual Studio support for UML 2.0, OCL, XMI, Design Patterns, Java 5, and CORBA/IDL Language Support: Eclipse Version Java and C++

Visual Studio Version C# and VB.NET

Database Support SQL Server, Oracle, DB2 and Sybase

Complex Software

http://www.intelligent-files.com/complex-software.html

Almost everything, around and about application software undergoing change, conspires to move it on from being just software, to being complex software Complex software arises from a culmination of many factors.
The

simplest measure of software complexity is via an algorithm called McCabe's Cyclomatic Complexity

Complex software can be defined through a summation of distinct measures.

Complex Software

http://www.intelligent-files.com/complex-software.html
Bringing complex software to ground level, this is what you feel, as a developer working with complex software:

complex software will make it hard to determine where to make a change to add a feature or fix a bug. complex software will cause what is called cascading changes. A simple change suddenly requires you to change ten, twenty, even thirty software files. complex software when changed will produced many unintended side effects, most of these being unwanted, even destructive. complex software will contain much duplication. This means, that for many changes, you will need to repeat yourself, sometimes many times over. complex software is hard to maitain. Data patches, manual releases, the lack of automated tests all add up to disempower IT maintenance teams.

Complex Software

http://www.intelligent-files.com/complex-software.html
Contibuting factors the developers, their psychology, fear, communication skills, desire for feedback. the business. its risk appetite, rewards structure, its ability to recruit & retain. the market. socio-economics, technology change, regulatory climate, customer mobility the project its leadership, sponsors, its agility & budget, its pace of development the competition systems, their technology & responsiveness, their differentiators the customertheir loyalty, their need for customization, their financial disposition

Ultra Large Scale (ULS) System

Ultra-large-scale system (ULSS) is a term used in fields including Computer Science, Software Engineering and Systems Engineering to refer to software intensive systems with unprecedented amounts of hardware, lines of source code, numbers of users, and volumes of data. The scale of these systems gives rise to many problems: they will be developed and used by many stakeholders across multiple organizations, often with conflicting purposes and needs; they will be constructed from heterogeneous parts with complex dependencies and emergent properties; they will be continuously evolving; and software, hardware and human failures will be the norm, not the exception.

(http://en.wikipedia.org/wiki/Ultra-large-scale_systems)

Ultra Large Scale Software Development

The scale and complexity

http://www.sei.cmu.edu/uls/

The scale and complexity of systems is increasing dramatically. Ultra-large-scale (ULS) systems are systems of unprecedented scale in some of these dimensions:

lines of code amount of data stored, accessed, manipulated, and refined number of connections and interdependencies number of hardware elements number of computational elements number of system purposes and user perception of these purposes number of routine processes, interactions, and emergent behaviors number of (overlapping) policy domains and enforceable mechanisms number of people involved in some way

Ultra-Large-Scale Systems; The Software Challenge of the Future (Software Engineering Institute Carnegie Mellon)

ULS System Characteristics

Decentralization

The scale of ULS systems means that they will necessarily be decentralized in a variety of waysdecentralized data, development, evolution, and operational control. ULS systems will be developed and used by a wide variety of stakeholders with unavoidably different, conflicting, complex, and changing needs. There will be an increasing need to integrate new capabilities into a ULS system while it is operating. New and different capabilities will be deployed, and unused capabilities will be dropped; the system will be evolving not in phases, but continuously.

Inherently conflicting, unknowable, and diverse requirements

Continuous evolution and deployment:

ULS System Characteristics (2)

Heterogeneous, inconsistent, and changing elements:

A ULS system will not be constructed from uniform parts: there will be some misfits, especially as the system is extended and repaired. People will not just be users of a ULS system; they will be elements of the system, affecting its overall emergent behavior. Software and hardware failures will be the norm rather than the exception. The acquisition of a ULS system will be simultaneous with the operation of the system and require new methods for control.

Erosion of the people/system boundary

Normal failures

New paradigms for acquisition and policy

Ultra-Large-Scale Systems; The Software Challenge of the Future (Software Engineering Institute Carnegie Mellon)

ULS Challenges

Design and Evolution Orchestration and Control Monitoring and Assessment

ULS Challenges (2)

Design and Evolution The challenge will be to find new ways to harness and coordinate the design capabilities and motivations not just of individual companies, prime contractors, and supply chains, but of whole industries, within which competition for value will drive much richer and more economical exploration of complex design spaces.

ULS Challenges (3)

Orchestration and Control

By orchestration we mean the set of activities needed to make the elements of a ULS system work in reasonable harmony to ensure continuous satisfaction of the mission objectives. Orchestration involves management and administration but at a scale well beyond that of traditional, centralized, relatively fine-grained controls. Orchestration requires a combination of up-front design, overall policy promulgation and enforcement, and real-time adjustment of operating parameters. Orchestrating a ULS system requires supporting interdependencies and controlling the consequences of local actions with respect to their effect on the emergent whole, even though each part of a system might be acting to maximize its local utility.

ULS Challenges (4)

To

succeed in developing and operating ULS systems, new knowledge, technologies, and methods in the following areas are needed:
online

modification maintenance of quality of service creation and execution of policies and rules adaptation to users and contexts
enabling

of user-controlled orchestration

ULS Challenges (5)

Monitoring and assessment

The

effectiveness of ULS system design, evolution, and orchestration has to be evaluated. There must be an ability to monitor and assess ULS system state, behavior, and overall health and well being. The criteria for success or overall health are different for ULS systems than for smaller systems designed to accomplish a task that does not change as the system is used.

Domains in which ULS Systems are emerging http://www.sei.cmu.edu/uls/

Defense The Northrop report argued that "the U.S. Department of Defense (DoD) has a goal of information dominance this goal depends on increasingly complex systems characterized by thousands of platforms, sensors, decision nodes, weapons, and warfighters connected through heterogeneous wired and wireless networks. These systems will push far beyond the size of today's systems by every measure They will be ultra-large-scale systems."[1]

Financial trading Following the flash crash, Cliff and Northrop[2] have argued "The very high degree of interconnectedness in the global markets means that entire trading systems, implemented and managed separately by independent organizations, can rightfully be considered as significant constituent entities in the larger global super-system. The sheer number of human agents and computer systems connected within the global financial-markets system-of-systems is so large that it is an instance of an ultra-large-scale system, and that largeness-of-scale has significant effects on the nature of the system".[2]

Domains.... (2)

Healthcare Kevin Sullivan has stated that the US healthcare system is "clearly an ultra-large-scale system"[7] and that building national scale cyberinfrastructure for healthcare "demands not just a rigorous, modern software and systems engineering effort, but an approach at the cutting edge of our understanding of information processing systems and their development and deployment in complex socio-technical environments".[7] Others Other domains said to be seeing the rise of ultra-large-scale systems include government, transport systems (for example air traffic control systems), energy distribution systems (for example smart grids) and large enterprises.

Managing Complexity

Software engineers have devised a number of fundamental tools of the trade for helping to manage complexity [1]:

Decomposition: The most basic technique for tackling large problems is to divide them into smaller, more manageable chunks, each of which can then be dealt with in relative isolation (note the nearly decomposable subsystems in Figure 1). Decomposition helps tackle complexity because it limits the designers scope. Abstraction: The process of defining a simplified model of the system that emphasizes some of the details or properties, while suppressing others. Again, this works because it limits the designers scope of interest at a given time. Organization: The process of defining and managing the interrelationships between the various problem-solving components (note the subsystem and interaction links of Figure 1). The ability to specify and enact organizational relationships helps designers tackle complexity by: enabling a number of basic components to be grouped together and treated as a higher-level unit of analysis, and providing a means of describing the highlevel relationships between various units.

[1] Booch, G. Object-Oriented Analysis and Design with Applications. Addison Wesley, 1994.

Very Large-Scale Software Engineering (VLSSE)

Architectural specification (system, services (data, protocols, processes), team/organization. Configuration management and version control Process automationbuilds, regression tests, etc. Reliance on informalisms for development
(Open Source Software Development and Very Large-Scale Software Engineering (Walt Scacchi Institute for Software Research University of California, Irvine Irvine, CA, 92697-3425 USA 19 July 2005))

VLSSE (2)

Information density vs. knowledge coverage VLSEE needs for ASB to consider:
Test-beds for full-size system mock-ups (probably built from OSS and Computer Game components) Visualization aidsarchitecture, configuration, sociotechnical networks Empirical knowledge about existing VLSEE practices for both OSS and CSS Computer-supported cooperative organizational learning environments (CSCOLE) supporting long-term organizational transformation.

VLSSE - The Process

Configuration management and version control Architectural specification and maintenance Collaboration, leadership, control and conflict management Community development and support Software source code and artifact data mining

Grady Boochs advices about making big software development projects a success

The fundamentals never go out of style, never forget the four fundamentals:

Create crisp and resilient abstractions. Maintain a good separation of concerns. Create a balanced distribution of responsibilities. Focus on simplicity. "Establishing that rhythm provides predictability and sustainability." Regularity lets everyone plan on what functionality or features will be injected into the next round, regardless of release frequency. IT managers need to govern around the architectural decisions rather than raw, running, naked code. "The code is the truth," Booch says. "But the code is not the whole truth.

You need a regular rhythm of releases.

Focus upon growing executable architectures.

Grady Boochs advices...

(http://www.cio.com/article/373215/5_Things_Grady_Booch_Has_Learned_About_C omplex_Software_Systems?page=2&taxonomyId=3020)

Create social structures that encourage innovation while still preserving predictability. Teamwork is an essential ingredient in any large software project, so companies should give attention to creating relationships that work. Businesses need predictability (when will this software really ship?) and they also want innovation (make it do something cool!). Building a social structure to support both those goals isn't necessarily easy, but the successful projects find a balance. Keeping developers out of "blasted meetings" so they can get things done. Have fun. Successful projects come from teams that are jazzed about what they're doing. "Most people want to build beautiful, elegant things,"

Tugas

Bagi kelompok @5 orang, dikumpul (Hardcopy) Selasa (3/9/2013) Cari paper terkait large scale atau complex software, pelajari, dan siapkan presentasi singkatnya (utk Selasa) Contoh:

Coordination in Large-Scale Software Team Survey answered by 775 Microsoft software engineers Parallel Changes in Large Scale Software Development: An Observational Study Coodination in Large-Scale Software Development: Helpful and Unhelpful Behaviors Defining Execution Viewpoints for a Large and Complex Software-Intensive System