240 likes | 452 Views
Personal Software Process Scalability. CIS 376 Bruce R. Maxim UM-Dearborn. These notes are based on: Introduction to the Personal Software Process Watts S. Humphrey Addison-Wesley Longman (1997). What is scalability all about?.
E N D
Personal Software ProcessScalability CIS 376 Bruce R. Maxim UM-Dearborn
These notes are based on: Introduction to the Personal Software Process Watts S. Humphrey Addison-Wesley Longman (1997)
What is scalability all about? • Using or adapting methods that work equally well on small projects to larger projects. • Scalability requires that elements of larger projects behave like small projects. • The product design must divide the project in to separately developed elements. • The development process must take the scale into account the scale of projects individuals can develop.
Scalability Stages Stage 0 - simple routines Stage 1 - programs Stage 2 - components/packages Stage 3 - systems Stage 4 - multi-systems
Scalability Stage 0 • Basic construct level (e.g. loops and conditionals) • Principle focus of intro programming courses • Design focus is on each individual construct • Designer often fails to visualize the impact of design decisions on larger program elements
Scalability Stage 1 • Small programs (up to several hundred LOC) • Movement from stage 0 to stage 1 occurs as programming language fluency increases • Programs are designed as whole without worrying about designing the details of each construct • Trusted function and object libraries and created and reused with confidence in new programs
Scalability Stage 2 • Multiple programs are combined to perform sophisticated functions • Components often several thousand LOC • Move from stage 1 occurs as experience grows • Designers conceive of programs that cannot be built by 1 person working alone • System issues begin to be addressed by designer
Scalability Stage 3 • Systems often several million LOC • System issues dominate • components must work together • components must all be high quality • Move from stage 2 involves • handling program complexity • understanding system and application issues • working in teams • Program quality must be the principle emphasis of the design process
Scalability Stage 4 • Products contain many millions of LOC • semi-independent systems must work together • quality is paramount • Move from stage 3 introduces distributed system issues and problems of maintaining centralized control • Requires semi-autonomous development groups and self-directing teams
Scalability Conditions - part 1 • To be scalable the • process must be managed • project must be managed • product must be managed • A managed process should • be defined • have the work divided into separable elements • integrate these elements into final system
Scalability Conditions - part 2 • In a managed project • work is planned • the plan is followed • changes are controlled • system design continues throughout the project • For a managed product • defects are tracked and controlled • integration and system testing is performed • regression testing is used consistently
Product Z Component X Component Y Module A Module D Module G Module J Module M Module B Module E Module H Module K Module N Module C Module F Module I Module L Module O The Scope of Scalability Large Project Medium Projects Small Projects
Scope of Scalability • In moving from module to component level you need to • maintain your module level quality and productivity • remember that the new component level work cannot be scaled up yet • In moving from component to product level you need to • maintain your component quality and productivity rate • remember that the product level work is new and cannot be scaled up
Managing Complexity - part 1 • Software size and complexity are closely related • Involves solving three related problems • how to write small high quality programs • enabling individuals to handle larger programs • combining individually developed programs into larger systems
Managing Complexity - part 2 • Humans have limited abilities to • remember details over time • visualize complex relationships • The principle tools for helping individuals develop more complex programs are • abstraction • architectural design • reuse
Architecture and Reuse - part 1 • System architectural design helps reduce complexity by • providing a coherent structural framework • identifying similar functions • permitting subsystem isolation • A good architectural design facilitates the use of standard designs by • deferring application specifics to the lowest levels • defining adjustable parameters when possible
Architecture and Reuse - part 2 • Using standard components enhances reusability • Standard components can be used as high-level design abstractions. • If these components are of high quality, scalability is more likely to be achieved
Feature-Oriented Domain Analysis • An architectural design method that • identifies conceptually similar functions • categorizes functions into classes • defines common abstractions for each class • uses parameters whenever possible • defers application-specific functions • permits maximun sharing of program elements
Feature-Oriented Domain Analysis Example • Define a system output function • The highest level composes and sends messages • The next lower level defines displays, and other interfaces • The next lower level handles printer formatting • The next lower level defines specific printer drivers
Cyclic PSP - part 1 • Provides a framework for using an incremental strategy to develop modest size programs • It is a larger process that contains many PSP2 elements • PSP requirements, planning, and postmortem steps are done once for the total program
Cyclic PSP • Requirements and Planning • High-level Design • High-Level Design Review • Cyclic Development • Postmortem • Integration and System Test
Requirements & Planning Specify Cycle High-level Design Detailed Design & Design Review HLD Review Test Development and Review Cyclic Development Implementation and Code Review Post- mortem Compile Integration System test Test Reassess and Recycle The Cyclic PSP Flow Specifications Product
Cyclic Development • Specify Cycle • Detailed Design • Detailed Design Review • Test Development • Test Review • Implementation • Code Review • Testing • Reassess and Recycle
Cyclic PSP Development Strategy • High level design partitions the program into smaller elements and determines the development strategy • The development strategy determines the cyclic steps involving • element selection • the testing strategy • final integration efforts