1. Large Scale Software Systems Derived from Dr. Fawcett’s Notes Phil Pratt-Szeliga Fall 2010

2. Software Complexity  “Software entities are more complex for their size than perhaps any other human construct, because no two parts are alike (at least above the statement level). If they are, we make the two similar parts into one, a subroutine”... “In this respect software systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound.”  “Digital computers are themselves more complex than most things people build. They have very large numbers of states. This makes conceiving, describing, and testing them hard. Software systems have orders of magnitude more states than computers do.”  Source: Frederick P. Brooks, Jr., “The Mythical Man- Month”

3. Software Complexity  “The complexity of software is an essential property, not an accidental one.”  “Many of the classical problems of developing software products derive from this essential complexity and its nonlinear increases with size.” – “...difficulty of communication among team members which leads to product flaws, cost overruns, schedule delays.” – “...difficulty of enumerating, much less understanding all the possible states of the program, and from that comes the unreliability.” Frederick P. Brooks, Jr., “The Mythical Man-Month”

4. Software Development Effort a program program product Completely tested and documented program system product program system consistent in format and function with other programs X3 effort X9 Effort for Program System Product 300 SLOC per day for a developer on a program 33 SLOC for a Program System Product Perhaps 22 SLOC in a team environment

5. Large Systems  Windows XP 40 Million SLOC 40,000,000 lines / 22 lines per day =  1,818,181 days 1,818,181 days / 240 days per year =  7575 person years of effort Building from scratch and finishing in 5 years requires 1515 well trained software developers  A system this large must be partitioned into small, nearly independent components  It is better not to start from scratch but to reuse software components

6. Software Development Process Models  Coordinating the activities of hundreds or thousands of people requires a detailed model of the process which everyone understands  Phases: Requirements Analysis Design Implementation Test

7. Software Development Process Models  Models for behavior and activities of people at various levels Project Manager Architect Team Leaders Team Members Support Personnel  Products of Each Development Phase What is created

8. Software Product Model  Architecture, OCD – defines product components and allocates processing to them – defines external product behavior  Requirements Specification, B-Spec – describes what constitutes correct operation – it is the basis for testing and evaluation  Product Specification, C-Spec – defines an architecture for the system – describes software design and implementation – specifies a software build process  Test Plan – defines procedures for unit, integration, validation, qualification, and regression testing – qualification test procedures are emphasized

9. Software Product Model  Prototype Code – verifies design for critical processing, analyzes implementation problems as they arise  Product Code – 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 Code – test drivers for unit, integration, and qualification tests  Test Report

10. Software Requirements Analysis  Requirements Analysis and preliminary design Breaking down in the application domain  Requirements are decomposed into processes and data flows Process – logical model of some activity necessary to satisfy part of requirement model Data flow – represents the information necessary to sustain activities of process  Each process in the B-Spec is allocated part of application’s requirements model May derive additional requirements to complete or disambiguate processing model

11. Software Requirements Analysis  Design Structure Developed by associating major processes with modules  Public interface of major modules represent associated process and data flow  Each stage of decomposition needs to allocate requirements to its component parts to prove correctness of the design

12. Products of Requirements Analysis  Team Leaders build B Level Specification from A Level Specification  A Level Specification Customer’s Requirements Specification  B Level Specification Developer’s Requirements Specification Specifies what will be build  Detailed specification review ensures that what is built satisfies the customer’s needs

13. Software Design Issues  Abstraction Logical model of component’s responsibilities  Modularity Partitioning into cohesive components  Cohesion A cohesive component should be focused on only one or two activities  Encapsulation Separating public interface from private implementation (building firewalls)  Hierarchy Delegating responsibilities

14. Software Design Issues  Coupling Each component should need to know as little as possible about other components Narrow coupling maximizes independence  Locality of Reference Data references by a component should be defined or declared by the component  Size and Complexity Each component is small and simple enough to test thoroughly  Object Oriented Design An object takes care of itself  Allocates resources needed  Cleans up after itself An object is a self contained processing entity which servers others though calls to its public interface

15. Software Implementation Issues  Modular Structure Manual Page Maintenance Page Public Interface Private Implementation Test Stub Test Drivers  Correct Operation Testing (Requires small size and complexity) Pre and Post Conditions Formalize assumptions Check Invariants

16. Software Testing  Construction Testing (build a little, test a little) Test stubs Testing invariants Incremental Development  Unit Testing (did I do it correctly?) Striving to make each component meet specifications  Integration Testing (will they come together?) Bringing separately developed components into the same build  Performance Testing (are there adequate margins?) Examine critical time-lines Memory and hard disk use

17. Software Testing  Validation Testing (does it crash?) Stress tests Pattern tests Random inputs  Qualification Testing (did we meet all requirements?) A legal verification that requirements have been met  Regression Testing (does it still work?) High level test of public operations Used:  When porting to new platforms  After Maintenance  When re-installing

18. Sources  Frederick P. Brooks, Jr., “The Mythical Man-Month”  Dr. Jim Fawcett Software Studio Class Notes – Chapter 1 – Large Scale Software Systems