BCS501

SOFTWARE ENGINEERING
AND PROJECT
MANAGEMENT
 COURSE OUTCOMES

• AT THE END OF THE COURSE THE STUDENT WILL BE ABLE TO:

• DIFFERENTIATE PROCESS MODELS TO JUDGE WHICH PROCESS
MODEL HAS TO BE ADOPTED FOR THE GIVEN SCENARIOS
• DERIVE BOTH FUNCTIONAL AND NON FUNCTIONAL
REQUIREMENTS FROM THE CASE STUDY
• ANALYZE THE IMPORTANCE OF VARIOUS SOFTWARE TESTING
METHODS AND AGILE METHODOLOGY
• ILLUSTRATE THE ROLE OF PROJECT PLANNING AND QUALITY
MANAGEMENT IN SOFTWARE DEVELOPMENT
• IDENTIFY APPROPRIATE TECHNIQUES TO ENHANCE SOFTWARE
QUALITY
• MODULE-1
SOFTWARE AND SOFTWARE ENGINEERING: THE NATURE OF
SOFTWARE, THE UNIQUE NATURE OF WEBAPPS, SOFTWARE
ENGINEERING, THE SOFTWARE PROCESS, THE SOFTWARE
ENGINEERING PRACTICE, THE SOFTWARE MYTHS
TEXTBOOK 1: CHAPTER 1: 1.1 TO 1.6
PROCESS MODELS: A GENERIC PROCESS MODEL, PROCESS
ASSESSMENT AND IMPROVEMENT, PRESCRIPTIVE PROCESS
MODELS, WATERFALL MODEL, INCREMENTAL PROCESS MODELS,
EVOLUTIONARY PROCESS MODELS, CONCURRENT MODELS,
SPECIALIZED PROCESS MODELS. UNIFIED PROCESS, PERSONAL
AND TEAM PROCESS MODELS
• TEXTBOOK 1: CHAPTER 2: 2.1 TO 2.5
• MODULE-2
UNDERSTANDING REQUIREMENTS: REQUIREMENTS ENGINEERING,
ESTABLISHING THE GROUND WORK, ELICITING REQUIREMENTS,
DEVELOPING USE CASES, BUILDING THE REQUIREMENTS MODEL,
NEGOTIATING REQUIREMENTS, VALIDATING REQUIREMENTS
• TEXTBOOK 1: CHAPTER 5: 5.1 TO 5.7
REQUIREMENTS MODELING SCENARIOS, INFORMATION AND ANALYSIS
CLASSES: REQUIREMENT ANALYSIS, SCENARIO BASED MODELING,
UML MODELS THAT SUPPLEMENT THE USE CASE, DATA MODELING
CONCEPTS CLASS BASED MODELING.
• TEXTBOOK 1: CHAPTER 6: 6.1 TO 6.5
• REQUIREMENT MODELLING STRATEGIES: FLOW ORIENTED
MODELLING, BEHAVIORAL MODELLING
• TEXTBOOK 1: CHAPTER 7: 7.1 TO 7.3
• MODULE-3
• AGILE DEVELOPMENT: WHAT IS AGILITY?, AGILITY AND
THE COST OF CHANGE. WHAT IS AN AGILE PROCESS?,
EXTREME PROGRAMMING (XP), OTHER AGILE PROCESS
MODELS, A TOOL SET FOR AGILE PROCESS PRINCIPLES
THAT GUIDE PRACTICE: SOFTWARE ENGINEERING
KNOWLEDGE, CORE PRINCIPLES, PRINCIPLES THAT
GUIDE EACH FRAMEWORK ACTIVITY
• TEXTBOOK 1: CHAPTER 3: 3.1 TO 3.6, CHAPTER 4: 4.1
TO 4.3
• MODULE-4
• INTRODUCTION TO PROJECT MANAGEMENT:
• INTRODUCTION, PROJECT AND IMPORTANCE OF PROJECT
MANAGEMENT, CONTRACT MANAGEMENT, ACTIVITIES COVERED BY
SOFTWARE PROJECT MANAGEMENT, PLANS, METHODS AND
METHODOLOGIES, SOME WAYS OF CATEGORIZING SOFTWARE
PROJECTS, STAKEHOLDERS, SETTING OBJECTIVES, BUSINESS CASE,
PROJECT SUCCESS AND FAILURE, MANAGEMENT AND MANAGEMENT
CONTROL, PROJECT MANAGEMENT LIFE CYCLE, TRADITIONAL VERSUS
MODERN PROJECT MANAGEMENT PRACTICES.
• TEXTBOOK 2: CHAPTER 1: 1.1 TO 1.17
• PROJECT EVALUATION: EVALUATION OF INDIVIDUAL PROJECTS, COST
BENEFIT EVALUATION TECHNIQUES, RISK EVALUATION
• TEXTBOOK 2: CHAPTER 2: 2.4 TO 2.6
• MODULE-5

• SOFTWARE QUALITY: INTRODUCTION, THE PLACE OF SOFTWARE

QUALITY IN PROJECT PLANNING, IMPORTANCE OF SOFTWARE
QUALITY, DEFINING SOFTWARE QUALITY, QUALITY MODELS,
PRODUCT VERSUS PROCESS QUALITY MANAGEMENT
• TEXTBOOK 2: CHAPTER 13: 13.1 TO 13.15
• SOFTWARE PROJECT ESTIMATION: OBSERVATIONS ON
ESTIMATIONS, DECOMPOSITION TECHNIQUES, EMPIRICAL
ESTIMATION MODELS
• TEXTBOOK 1: CHAPTER 26: 26.5 TO 26.7
• TEXTBOOKS
• 1. ROGER S. PRESSMAN: SOFTWARE ENGINEERING-A
PRACTITIONERS APPROACH, 7TH EDITION, TATA MCGRAW HILL.
• 2. BOB HUGHES, MIKE COTTERELL, RAJIB MALL: SOFTWARE
PROJECT MANAGEMENT, 6TH EDITION, MCGRAW HILL EDUCATION,
2018.
• REFERENCE:
• 1. PANKAJ JALOTE: AN INTEGRATED APPROACH TO SOFTWARE
ENGINEERING, WILEY INDIA.
• “SOFTWARE ENGINEERING: PRINCIPLES AND PRACTICE, HANS VAN
VLIET, WILEY INDIA ,3RD EDITION 2010
 THE NATURE OF SOFTWARE
• SOFTWARE TAKES ON A DUAL ROLE. IT IS A PRODUCT, AND AT THE
SAME TIME, THE VEHICLE FOR DELIVERING A PRODUCT.
• SOFTWARE IS AN INFORMATION TRANSFORMER—PRODUCING,
MANAGING, ACQUIRING, MODIFYING, DISPLAYING, OR TRANSMITTING
INFORMATION THAT CAN BE AS SIMPLE AS A SINGLE BIT OR AS
COMPLEX AS A MULTIMEDIA PRESENTATION
• AS THE VEHICLE USED TO DELIVER THE PRODUCT, SOFTWARE ACTS AS
• THE BASIS FOR THE CONTROL OF THE COMPUTER (OPERATING
SYSTEMS),
• THE COMMUNICATION OF INFORMATION (NETWORKS),
• AND THE CREATION AND CONTROL OF OTHER PROGRAMS
(SOFTWARE TOOLS AND ENVIRONMENTS).
• SOFTWARE DELIVERS THE MOST IMPORTANT PRODUCT OF OUR
TIME—INFORMATION.
• IT TRANS- FORMS PERSONAL DATA (E.G., AN INDIVIDUAL’S
FINANCIAL TRANSACTIONS) SO THAT THE DATA CAN BE MORE
USEFUL IN A LOCAL CONTEXT;
• IT MANAGES BUSINESS INFORMATION TO ENHANCE
COMPETITIVENESS;
• IT PROVIDES A GATEWAY TO WORLDWIDE INFORMATION
NETWORKS (E.G., THE INTERNET), AND PROVIDES THE MEANS FOR
ACQUIRING INFORMATION IN ALL OF ITS FORMS
DEFINING SOFTWARE:
• SOFTWARE IS:
(1) INSTRUCTIONS (COMPUTER PROGRAMS) THAT
WHEN EXECUTED PROVIDE DESIRED FEATURES,
FUNCTION, AND PERFORMANCE;

(2) DATA STRUCTURES THAT ENABLE THE PROGRAMS TO

ADEQUATELY MANIPULATE INFORMATION, AND

(3) DESCRIPTIVE INFORMATION IN BOTH HARD COPY

AND VIRTUAL
FORMS THAT DESCRIBES THE OPERATION AND USE OF
THE PROGRAMS
• SOFTWARE IS LOGICAL RATHER THAN A PHYSICAL SYSTEM ELEMENT.
THEREFORE, SOFTWARE HAS CHARACTERISTICS THAT ARE CONSIDERABLY DIFFERENT
THAN THOSE OF HARDWARE:
1. SOFTWARE IS DEVELOPED OR ENGINEERED; IT IS NOT MANUFACTURED IN
THE CLASSICAL SENSE.
• IN BOTH ACTIVITIES, HIGH QUALITY IS ACHIEVED THROUGH GOOD DESIGN, BUT
THE MANUFACTURING PHASE FOR HARDWARE CAN INTRODUCE QUALITY
PROBLEMS THAT ARE NONEXISTENT (OR EASILY CORRECTED) FOR SOFTWARE.
• BOTH ACTIVITIES ARE DEPENDENT ON PEOPLE, BUT THE RELATIONSHIP
BETWEEN PEOPLE APPLIED AND WORK ACCOMPLISHED IS ENTIRELY DIFFERENT
• BOTH ACTIVITIES REQUIRE THE CONSTRUCTION OF A “PRODUCT,” BUT THE
APPROACHES ARE DIFFERENT
• SOFTWARE COSTS ARE CONCENTRATED IN ENGINEERING. THIS MEANS THAT
SOFTWARE PROJECTS CANNOT BE MANAGED AS IF THEY WERE MANUFACTURING
PROJECTS.
2. SOFTWARE DOESN’T “WEAR OUT”
• THE RELATIONSHIP, OFTEN CALLED THE “BATHTUB CURVE,” INDICATES THAT
HARDWARE EXHIBITS RELATIVELY HIGH FAILURE RATES EARLY IN ITS LIFE DEFECTS.
THESE ARE CORRECTED AND THE FAILURE RATE DROPS TO A STEADY-STATE LEVEL.
• AS TIME PASSES, HOWEVER, THE FAILURE RATE RISES AGAIN AS HARDWARE
COMPONENTS SUFFER FROM THE CUMULATIVE EFFECTS OF DUST, VIBRATION,
ABUSE, TEMPERATURE EXTREMES, AND MANY OTHER ENVIRONMENTAL MALADIES.
STATED SIMPLY, THE HARDWARE BEGINS TO WEAR OUT.
• SOFTWARE IS NOT SUSCEPTIBLE TO THE ENVIRONMENTAL MALADIES THAT CAUSE
HARDWARE TO WEAR OUT.
• UNDISCOVERED DEFECTS WILL CAUSE HIGH FAILURE RATES EARLY IN THE LIFE OF
A PROGRAM
• HOWEVER, THE IMPLICATION IS CLEAR—SOFTWARE DOESN’T WEAR OUT. BUT
IT DOES
DETERIORATE!
FAILURE CURVE FOR HARDWARE
• WHEN A HARDWARE COMPONENT WEARS OUT, IT IS REPLACED BY A
SPARE PART. THERE ARE NO SOFTWARE SPARE PARTS.
• EVERY SOFTWARE FAILURE INDICATES AN ERROR IN DESIGN OR IN THE
PROCESS THROUGH WHICH DESIGN WAS TRANSLATED INTO MACHINE
EXECUTABLE CODE. THEREFORE, THE SOFTWARE MAINTENANCE TASKS THAT
ACCOMMODATE REQUESTS FOR CHANGE INVOLVE CONSIDERABLY MORE
COMPLEXITY THAN HARDWARE MAINTENANCE.
3.ALTHOUGH THE INDUSTRY IS MOVING TOWARD COMPONENT-BASED
CONSTRUCTION, MOST SOFTWARE CONTINUES TO BE CUSTOM BUILT
• STANDARD SCREWS AND OFF-THE-SHELF INTEGRATED CIRCUITS ARE ONLY TWO
OF THOUSANDS OF STANDARD COMPONENTS THAT ARE USED BY MECHANICAL
AND ELECTRICAL ENGINEERS AS THEY DESIGN NEW SYSTEMS.
• IN THE HARDWARE WORLD, COMPONENT REUSE IS A
NATURAL PART OF THE ENGINEERING PROCESS. IN THE
SOFTWARE WORLD, IT IS SOMETHING THAT HAS ONLY
BEGUN TO BE ACHIEVED ON A BROAD SCALE.
• A SOFTWARE COMPONENT SHOULD BE DESIGNED AND
IMPLEMENTED SO THAT IT CAN BE REUSED IN MANY DIFFERENT
PROGRAMS.
• MODERN REUSABLE COMPONENTS ENCAPSULATE BOTH DATA AND
THE PROCESSING THAT IS APPLIED TO THE DATA, ENABLING THE
SOFTWARE ENGINEER TO CREATE NEW APPLICATIONS FROM
REUSABLE PARTS
• SOFTWARE APPLICATION DOMAINS
1.SYSTEM SOFTWARE
• A COLLECTION OF PROGRAMS WRITTEN TO SERVICE OTHER PROGRAMS.
SOME SYSTEM SOFTWARE (E.G., COMPILERS, EDITORS, AND FILE MANAGEMENT
UTILITIES) PROCESSES COMPLEX, BUT DETERMINATE, INFORMATION
STRUCTURES.
• OTHER SYSTEMS APPLICATIONS (E.G., OPERATING SYSTEM COMPONENTS,
DRIVERS, NETWORKING SOFTWARE, TELECOMMUNICATIONS PROCESSORS)
PROCESS LARGELY INDETERMINATE DATA.
• THE SYSTEMS SOFTWARE AREA IS CHARACTERIZED BY
• HEAVY INTERACTION WITH COMPUTER HARDWARE
• HEAVY USAGE BY MULTIPLE USERS; CONCURRENT OPERATION THAT
REQUIRES SCHEDULING, RESOURCE SHARING
• AND SOPHISTICATED PROCESS MANAGEMENT; COMPLEX DATA STRUCTURES;
AND MULTIPLE EXTERNAL INTERFACES
2.APPLICATION SOFTWARE.
• STAND-ALONE PROGRAMS THAT SOLVE A SPECIFIC BUSINESS NEED.
• APPLICATIONS IN THIS AREA HELPS BUSINESS OPERATIONS OR
MANAGEMENT/TECHNICAL DECISION MAKING. IN ADDITION TO CONVENTIONAL
DATA PROCESSING APPLICATIONS
• APPLICATION SOFTWARE IS USED TO CONTROL BUSINESS FUNCTIONS IN REAL
TIME (E.G., POINT-OF-SALE TRANSACTION PROCESSING, REAL-TIME
MANUFACTURING PROCESS CONTROL
• EG. MICROSOFT PRODUCTS LIKE MS OFFICE, POWER POINT
• BROWSERS LIKE FIREFOX,GOOGLE CHROME
3.ENGINEERING/SCIENTIFIC SOFTWARE
• HAS BEEN CHARACTERIZED BY “NUMBER CRUNCHING” ALGORITHMS.
• APPLICATIONS RANGE FROM ASTRONOMY TO VOLCANOLOGY, FROM
AUTOMOTIVE STRESS ANALYSIS TO SPACE SHUTTLE ORBITAL DYNAMICS, AND
FROM MOLECULAR BIOLOGY TO AUTOMATED MANUFACTURING
4. EMBEDDED SOFTWARE
• RESIDES WITHIN A PRODUCT OR SYSTEM
• USED TO IMPLEMENT AND CONTROL FEATURES AND FUNCTIONS FOR THE END
USER AND FOR THE SYSTEM ITSELF.
• EMBEDDED SOFTWARE CAN PERFORM LIMITED AND ESOTERIC FUNCTIONS
(E.G., KEY PAD CONTROL FOR A MICROWAVE OVEN) OR PROVIDE SIGNIFICANT
FUNCTION AND CONTROL CAPABILITY (E.G., DIGITAL FUNCTIONS IN AN
AUTOMOBILE SUCH AS FUEL CONTROL, DASHBOARD DISPLAYS, AND BRAKING
SYSTEMS).
5.PRODUCT-LINE SOFTWARE
• DESIGNED TO PROVIDE A SPECIFIC CAPABILITY FOR USE BY MANY DIFFERENT
CUSTOMERS.
• PRODUCT-LINE SOFTWARE CAN FOCUS ON A LIMITED AND ESOTERIC MARKETPLACE (E.G.,
INVENTORY CONTROL PRODUCTS) OR ADDRESS MASS CONSUMER MARKETS (E.G., WORD
PROCESSING, SPREADSHEETS, COMPUTER GRAPHICS, MULTIMEDIA, ENTERTAINMENT,
DATABASE MANAGEMENT, AND PERSONAL AND BUSINESS FINANCIAL APPLICATIONS).
6.WEB APPLICATIONS
• CALLED “WEBAPPS,” THIS NETWORK-CENTRIC SOFTWARE CATEGORY SPANS A WIDE
ARRAY OF APPLICATIONS
• WEBAPPS CAN BE LITTLE MORE THAN A SET OF LINKED HYPERTEXT FILES THAT PRESENT
INFORMATION USING TEXT AND LIMITED GRAPHICS.
• WEBAPPS ARE EVOLVING INTO SOPHISTICATED COMPUTING ENVIRONMENTS THAT NOT
ONLY PROVIDE STAND-ALONE FEATURES, COMPUTING FUNCTIONS, AND CONTENT TO THE
END USER, BUT ALSO ARE INTEGRATED WITH CORPORATE DATABASES AND BUSINESS
APPLICATIONS.
7. ARTIFICIAL INTELLIGENCE SOFTWARE
• MAKES USE OF NONNUMERICAL ALGORITHMS TO SOLVE COMPLEX PROBLEMS
THAT ARE NOT AMENABLE TO COMPUTATION OR STRAIGHT FORWARD
ANALYSIS.
• APPLICATIONS WITHIN THIS AREA INCLUDE ROBOTICS, EXPERT SYSTEMS,
PATTERN RECOGNITION (IMAGE AND VOICE), ARTIFICIAL NEURAL NETWORKS,
THEOREM PROVING, AND GAME PLAYING
CHALLENGES FACED BY SOFTWARE ENGINEERS:
1.OPEN-WORLD COMPUTING
• THE RAPID GROWTH OF WIRELESS NETWORKING MAY SOON LEAD TO TRUE
PERVASIVE, DISTRIBUTED COMPUTING.
• THE CHALLENGE FOR SOFTWARE ENGINEERS WILL BE TO DEVELOP SYSTEMS
AND APPLICATION SOFTWARE THAT WILL ALLOW MOBILE DEVICES, PERSONAL
COMPUTERS, AND ENTERPRISE SYSTEMS TO COMMUNICATE ACROSS
2. NETSOURCING:
• THE WORLD WIDE WEB IS RAPIDLY BECOMING A COMPUTING ENGINE AS WELL AS A
CONTENT PROVIDER.
• THE CHALLENGE FOR SOFTWARE ENGINEERS IS TO ARCHITECT SIMPLE (E.G.,
PERSONAL FINANCIAL PLANNING) AND SOPHISTICATED APPLICATIONS THAT
PROVIDE A BENEFIT TO TARGETED END-USER MARKETS WORLDWIDE.
3.OPEN SOURCE
• A GROWING TREND THAT RESULTS IN DISTRIBUTION OF SOURCE CODE FOR SYSTEMS
APPLICATIONS (E.G., OPERATING SYSTEMS, DATABASE, AND DEVELOPMENT
ENVIRONMENTS) SO THAT MANY PEOPLE CAN CONTRIBUTE TO ITS DEVELOPMENT.
• THE CHALLENGE FOR SOFTWARE ENGINEERS IS TO BUILD SOURCE CODE
THAT IS SELF-DESCRIPTIVE, BUT MORE IMPORTANTLY, TO DEVELOP TECHNIQUES
THAT WILL ENABLE BOTH CUSTOMERS AND DEVELOPERS TO KNOW WHAT CHANGES
HAVE BEEN MADE AND HOW THOSE CHANGES MANIFEST THEMSELVES WITHIN THE
SOFTWARE
 LEGACY SOFTWARE:
LEGACY SOFTWARE SYSTEMS . . . WERE DEVELOPED DECADES AGO
AND HAVE BEEN CONTINUALLY MODIFIED TO MEET CHANGES IN
BUSINESS REQUIREMENTS AND COMPUTING PLATFORMS. THE
PROLIFERATION OF SUCH SYSTEMS IS CAUSING HEADACHES FOR LARGE
ORGANIZATIONS WHO FIND THEM COSTLY TO MAINTAIN AND RISKY TO
EVOLVE.
AS TIME PASSES, LEGACY SYSTEMS OFTEN EVOLVE FOR ONE OR MORE OF THE
FOLLOWING REASONS:
• THE SOFTWARE MUST BE ADAPTED TO MEET THE NEEDS OF NEW
COMPUTING ENVIRON- MENTS OR TECHNOLOGY.
• THE SOFTWARE MUST BE ENHANCED TO IMPLEMENT NEW BUSINESS
REQUIREMENTS.
• THE SOFTWARE MUST BE EXTENDED TO MAKE IT INTEROPERABLE WITH
OTHER MORE MODERN SYSTEMS OR DATABASES.
• THE SOFTWARE MUST BE RE-ARCHITECTED TO MAKE IT VIABLE WITHIN
THE UNIQUE NATURE OF WEB APPS
• NETWORK INTENSIVENESS. A WEBAPP RESIDES ON A NETWORK AND
MUST SERVE THE NEEDS OF A DIVERSE COMMUNITY OF CLIENTS. THE
NETWORK MAY ENABLE WORLD- WIDE ACCESS AND COMMUNICATION (I.E.,
THE INTERNET) OR MORE LIMITED ACCESS AND COMMUNICATION (E.G., A
CORPORATE INTRANET).
• CONCURRENCY. A LARGE NUMBER OF USERS MAY ACCESS THE
WEBAPP AT ONE TIME. IN MANY CASES, THE PATTERNS OF USAGE AMONG
END USERS WILL VARY GREATLY.
• UNPREDICTABLE LOAD. THE NUMBER OF USERS OF THE WEBAPP MAY
VARY BY ORDERS OF MAGNITUDE FROM DAY TO DAY. ONE HUNDRED
USERS MAY SHOW UP ON MONDAY; 10,000 MAY USE THE SYSTEM ON
THURSDAY.
• PERFORMANCE. IF A WEBAPP USER MUST WAIT TOO LONG (FOR ACCESS,
FOR SERVER- SIDE PROCESSING, FOR CLIENT-SIDE FORMATTING AND
DISPLAY), HE OR SHE MAY DECIDE TO GO ELSEWHERE.
• AVAILABILITY. ALTHOUGH EXPECTATION OF 100 PERCENT AVAILABILITY IS
UNREASONABLE, USERS OF POPULAR WEBAPPS OFTEN DEMAND ACCESS ON A
24/7/365 BASIS. USERS IN AUSTRALIA OR ASIA MIGHT DEMAND ACCESS DURING
TIMES WHEN TRADITIONAL DOMESTIC SOFTWARE APPLICATIONS IN NORTH AMERICA
MIGHT BE TAKEN OFF-LINE FOR MAINTENANCE.
• DATA DRIVEN. THE PRIMARY FUNCTION OF MANY WEBAPPS IS TO USE
HYPERMEDIA TO PRESENT TEXT, GRAPHICS, AUDIO, AND VIDEO CONTENT
TO THE END USER. IN ADDITION, WEBAPPS ARE COMMONLY USED TO ACCESS
INFORMATION THAT EXISTS ON DATABASES THAT ARE NOT AN INTEGRAL PART OF
THE WEB-BASED ENVIRONMENT (E.G.,E-COMMERCE OR FINANCIAL APPLICATIONS).
• CONTENT SENSITIVE. THE QUALITY AND AESTHETIC NATURE OF CONTENT
REMAINS AN IMPORTANT DETERMINANT OF THE QUALITY OF A WEBAPP.
• CONTINUOUS EVOLUTION. UNLIKE CONVENTIONAL APPLICATION SOFTWARE
THAT EVOLVES OVER A SERIES OF PLANNED, CHRONOLOGICALLY SPACED RELEASES,
WEB APPLI- CATIONS EVOLVE CONTINUOUSLY. IT IS NOT UNUSUAL FOR SOME
WEBAPPS (SPECIFICALLY, THEIR CONTENT) TO BE UPDATED ON A MINUTE-BY-MINUTE
SCHEDULE OR FOR CONTENT TO BE INDEPENDENTLY COMPUTED FOR EACH
REQUEST.
• IMMEDIACY. ALTHOUGH IMMEDIACY—THE COMPELLING NEED TO GET SOFTWARE TO
MARKET QUICKLY—IS A CHARACTERISTIC OF MANY APPLICATION DOMAINS, WEBAPPS
OFTEN EXHIBIT A TIME-TO-MARKET THAT CAN BE A MATTER OF A FEW DAYS OR WEEKS.

• SECURITY. BECAUSE WEBAPPS ARE AVAILABLE VIA NETWORK ACCESS, IT IS

DIFFICULT, IF NOT IMPOSSIBLE, TO LIMIT THE POPULATION OF END USERS WHO MAY
ACCESS THE APPLICATION. IN ORDER TO PROTECT SENSITIVE CONTENT AND PROVIDE
SECURE MODES OF DATA TRANSMISSION, STRONG SECURITY MEASURES MUST BE
IMPLEMENTED THROUGHOUT THE INFRASTRUCTURE THAT SUPPORTS A WEBAPP AND
WITHIN THE APPLI- CATION ITSELF.

• AESTHETICS. AN UNDENIABLE PART OF THE APPEAL OF A WEBAPP IS ITS LOOK AND

FEEL. WHEN AN APPLICATION HAS BEEN DESIGNED TO MARKET OR SELL PRODUCTS OR
IDEAS, AESTHETICS MAY HAVE AS MUCH TO DO WITH SUCCESS AS TECHNICAL DESIGN.
SOFTWARE ENGINEERING
IN ORDER TO BUILD SOFTWARE THAT IS READY TO MEET THE CHALLENGES OF THE TWENTY-
FIRST CENTURY, YOU MUST RECOGNIZE A FEW SIMPLE REALITIES:
1. A CONCERTED EFFORT SHOULD BE MADE TO UNDERSTAND THE PROBLEM
BEFORE A SOFTWARE SOLUTION IS DEVELOPED.
• WHEN A NEW APPLICATION OR EMBEDDED SYSTEM IS TO BE BUILT EACH PERSON HAS A
SLIGHTLY DIFFERENT IDEA OF WHAT SOFTWARE FEATURES AND FUNCTIONS
SHOULD BE DELIVERED

2. DESIGN BECOMES A PIVOTAL ACTIVITY.

• THE INFORMATION TECHNOLOGY REQUIREMENTS DEMANDED BY INDIVIDUALS, BUSI-
NESSES, AND GOVERNMENTS GROW INCREASING COMPLEX WITH EACH PASSING YEAR.
• SOPHISTICATED SOFTWARE THAT WAS ONCE IMPLEMENTED IN A PREDICTABLE, SELF-
CONTAINED, COMPUTING ENVIRONMENT IS NOW EMBEDDED INSIDE EVERYTHING
FROM CONSUMER ELECTRONICS TO MEDICAL DEVICES TO WEAPONS SYSTEMS.
• THE COMPLEXITY OF THESE NEW COMPUTER-BASED SYSTEMS AND PRODUCTS
DEMANDS CAREFUL ATTENTION TO THE INTERACTIONS OF ALL SYSTEM ELEMENTS
3. SOFTWARE SHOULD EXHIBIT HIGH QUALITY.
• INDIVIDUALS, BUSINESSES, AND GOVERNMENTS INCREASINGLY RELY ON SOFTWARE
FOR STRATEGIC AND TACTICAL DECISION MAKING AS WELL AS DAY-TO-DAY OPERATIONS
AND CONTROL.
• IF THE SOFTWARE FAILS, PEOPLE AND MAJOR ENTERPRISES CAN EXPERIENCE
ANYTHING FROM MINOR INCONVENIENCE TO CATASTROPHIC FAILURES

4. SOFTWARE SHOULD BE MAINTAINABLE.

• AS THE PERCEIVED VALUE OF A SPECIFIC APPLICATION GROWS, THE LIKELIHOOD IS
THAT ITS USER BASE AND LONGEVITY WILL ALSO GROW. AS ITS USER BASE AND TIME-
IN-USE INCREASE, DEMANDS FOR ADAPTATION AND ENHANCEMENT WILL ALSO GROW

THESE SIMPLE REALITIES LEAD TO ONE CONCLUSION: SOFTWARE IN ALL OF ITS

FORMS AND ACROSS ALL OF ITS APPLICATION DOMAINS SHOULD BE
ENGINEERED.
• A DEFINITION PROPOSED BY FRITZ BAUER [NAU69] AT THE SEMINAL
CONFERENCE ON THE SUBJECT STILL SERVES AS A BASIS FOR DISCUSSION:
• [SOFTWARE ENGINEERING IS] THE ESTABLISHMENT AND USE OF
SOUND ENGINEERING PRINCIPLES IN ORDER TO OBTAIN
ECONOMICALLY SOFTWARE THAT IS RELIABLE AND WORKS
EFFICIENTLY ON REAL MACHINES.
• IT SAYS LITTLE ABOUT THE TECHNICAL ASPECTS OF SOFTWARE QUALITY;
• IT DOES NOT DIRECTLY ADDRESS THE NEED FOR CUSTOMER
SATISFACTION OR TIMELY PRODUCT DELIVERY;
• IT OMITS MENTION OF THE IMPORTANCE OF MEASUREMENT AND
METRICS;
• IT DOES NOT STATE THE IMPORTANCE OF AN EFFECTIVE PROCESS.
• AND YET, BAUER’S DEFINITION PROVIDES US WITH A BASELINE.
• WHAT ARE THE “SOUND ENGINEERING PRINCIPLES” THAT CAN
BE APPLIED TO COMPUTER SOFTWARE DEVELOPMENT?
• HOW DO WE “ECONOMICALLY” BUILD SOFTWARE SO THAT IT IS
“RELIABLE”?
• WHAT IS REQUIRED TO CREATE COMPUTER PROGRAMS THAT
WORK “EFFICIENTLY” ON NOT ONE BUT MANY DIFFERENT “REAL
MACHINES”?
• THESE ARE THE QUESTIONS THAT CONTINUE TO CHALLENGE
SOFTWARE ENGINEERS.
• THE IEEE [IEE93A] HAS DEVELOPED A MORE COMPREHENSIVE
DEFINITION WHEN IT STATES:
• SOFTWARE ENGINEERING:
(1) THE APPLICATION OF A SYSTEMATIC, DISCIPLINED,
QUANTIFIABLE APPROACH TO THE DEVELOPMENT, OPERATION, AND
MAINTENANCE OF SOFTWARE; THAT IS, THE APPLICATION OF
ENGINEERING TO SOFTWARE. (2) THE STUDY OF APPROACHES AS
IN (1).

• AND YET, A “SYSTEMATIC, DISCIPLINED, AND QUANTIFIABLE”

APPROACH APPLIED BY ONE SOFTWARE TEAM MAY BE BURDENSOME
TO ANOTHER. WE NEED DISCIPLINE, BUT WE ALSO NEED
ADAPTABILITY AND AGILITY
SOFTWARE ENGINEERING LAYERS
• SOFTWARE ENGINEERING IS A LAYERED TECHNOLOGY
• ANY ENGINEERING APPROACH (INCLUDING SOFTWARE
ENGINEERING) MUST REST ON AN ORGANIZATIONAL
COMMITMENT TO QUALITY.
• TOTAL QUALITY MANAGEMENT, SIX SIGMA, AND SIMILAR
PHILOSOPHIES FOSTER A CONTINUOUS PROCESS IMPROVEMENT
CULTURE, AND IT IS THIS CULTURE THAT ULTIMATELY LEADS TO
THE DEVELOPMENT OF INCREASINGLY MORE EFFECTIVE
APPROACHES TO SOFTWARE ENGINEERING.
• THE BEDROCK THAT SUPPORTS SOFTWARE ENGINEERING IS A
QUALITY FOCUS.
• THE FOUNDATION FOR SOFTWARE ENGINEERING IS THE
PROCESS LAYER.
• THE SOFTWARE ENGINEERING PROCESS IS THE GLUE THAT
HOLDS THE TECHNOLOGY LAYERS TOGETHER AND ENABLES
RATIONAL AND TIMELY DEVELOPMENT OF COMPUTER
SOFTWARE.
• PROCESS DEFINES A FRAMEWORK THAT MUST BE
ESTABLISHED FOR EFFECTIVE DELIVERY OF SOFTWARE
ENGINEERING TECHNOLOGY
• THE SOFTWARE PROCESS FORMS THE BASIS FOR MANAGEMENT
CONTROL OF SOFTWARE PROJECTS AND ESTABLISHES THE
CONTEXT IN WHICH TECHNICAL METHODS ARE APPLIED, WORK
• SOFTWARE ENGINEERING METHODS PROVIDE THE TECHNICAL HOW-TO’S
FOR BUILDING SOFT WARE.
• METHODS ENCOMPASS A BROAD ARRAY OF TASKS THAT INCLUDE
COMMUNICATION, REQUIREMENTS ANALYSIS, DESIGN MODELING,
PROGRAM CONSTRUCTION, TESTING, AND SUP PORT.
• SOFTWARE ENGINEERING METHODS RELY ON A SET OF BASIC PRINCIPLES
THAT GOVERN EACH AREA OF THE TECHNOLOGY AND INCLUDE MODELING
ACTIVITIES AND OTHER DESCRIPTIVE TECHNIQUES.
• SOFTWARE ENGINEERING TOOLS PROVIDE AUTOMATED OR
SEMIAUTOMATED SUPPORT FOR THE PROCESS AND THE METHODS.
• WHEN TOOLS ARE INTEGRATED SO THAT INFORMATION CREATED BY ONE
TOOL CAN BE USED BY ANOTHER, A SYSTEM FOR THE SUPPORT OF
SOFTWARE DEVELOPMENT, CALLED COMPUTER-AIDED SOFTWARE
ENGINEERING, IS ESTABLISHED
 SOFTWARE PROCESS
• A PROCESS IS A COLLECTION OF ACTIVITIES, ACTIONS, AND TASKS THAT
ARE PERFORMED WHEN SOME WORK PRODUCT IS TO BE CREATED.
• AN ACTIVITY STRIVES TO ACHIEVE A BROAD OBJECTIVE (E.G.,
COMMUNICATION WITH STAKEHOLDERS) AND IS APPLIED REGARDLESS OF
THE APPLICATION DOMAIN, SIZE OF THE PROJECT, COMPLEXITY OF THE
EFFORT, OR DEGREE OF RIGOR WITH WHICH SOFTWARE ENGINEERING IS TO
BE APPLIED.
• AN ACTION (E.G., ARCHITECTURAL DESIGN) ENCOMPASSES A SET OF TASKS
THAT PRODUCE A MAJOR WORK PRODUCT (E.G., AN ARCHITECTURAL DESIGN
MODEL).
• A TASK FOCUSES ON A SMALL, BUT WELL-DEFINED OBJECTIVE (E.G.,
CONDUCTING A UNIT TEST) THAT PRODUCES A TANGIBLE OUTCOME.
• IN THE CONTEXT OF SOFTWARE ENGINEERING, A PROCESS IS NOT A RIGID
PRESCRIPTION FOR HOW TO BUILD COMPUTER SOFTWARE.
• RATHER, IT IS AN ADAPTABLE APPROACH THAT ENABLES THE PEOPLE
DOING THE WORK (THE SOFTWARE TEAM) TO PICK AND CHOOSE THE
APPROPRIATE SET OF WORK ACTIONS AND TASKS.
• THE INTENT IS ALWAYS TO DELIVER SOFTWARE IN A TIMELY MANNER AND
WITH SUFFICIENT QUALITY TO SATISFY THOSE WHO HAVE SPONSORED ITS
CREATION AND THOSE WHO WILL USE IT
• A PROCESS FRAMEWORK ESTABLISHES THE FOUNDATION FOR
A COMPLETE SOFTWARE ENGINEERING PROCESS BY
IDENTIFYING A SMALL NUMBER OF FRAMEWORK ACTIVITIES
THAT ARE APPLICABLE TO ALL SOFTWARE PROJECTS,
REGARDLESS OF THEIR SIZE OR COMPLEXITY.
• A GENERIC PROCESS FRAMEWORK FOR SOFTWARE ENGI
NEERING ENCOMPASSES FIVE ACTIVITIES:
1. COMMUNICATION.
• BEFORE ANY TECHNICAL WORK CAN COMMENCE, IT IS
CRITICALLY IMPORTANT TO COMMUNICATE AND
COLLABORATE WITH THE CUSTOMER (AND OTHER
STAKEHOLDERS-
• THE INTENT IS TO UNDERSTAND STAKEHOLDERS’
2.PLANNING.
• ANY COMPLICATED JOURNEY CAN BE SIMPLIFIED IF A MAP EXISTS.
• A SOFTWARE PROJECT IS A COMPLICATED JOURNEY, AND THE
PLANNING ACTIVITY CREATES A “MAP” THAT HELPS GUIDE THE TEAM
AS IT MAKES THE JOURNEY.
• THE MAP—CALLED A SOFTWARE PROJECT PLAN—DEFINES THE SOFTWARE
ENGINEERING WORK BY DESCRIBING THE TECHNICAL TASKS TO BE
CONDUCTED, THE RISKS THAT ARE LIKELY, THE RESOURCES THAT WILL
BE REQUIRED, THE WORK PRODUCTS TO BE PRODUCED, AND A WORK
SCHEDULE.
3. MODELING.
• YOU CREATE A “SKETCH” OF THE THING SO THAT YOU’LL
UNDERSTAND THE BIG PICTURE—WHAT IT WILL LOOK LIKE
ARCHITECTURALLY, HOW THE CONSTITUENT PARTS FIT TOGETHER, AND
MANY OTHER CHARACTERISTICS.
• IF REQUIRED, YOU REFINE THE SKETCH INTO GREATER AND GREATER DETAIL
IN AN EFFORT TO BETTER UNDERSTAND THE PROBLEM AND HOW YOU’RE
GOING TO SOLVE IT.
• A SOFTWARE ENGINEER DOES THE SAME THING BY CREATING MODELS TO
BETTER UNDERSTAND SOFTWARE REQUIREMENTS AND THE DESIGN THAT
WILL ACHIEVE THOSE REQUIREMENTS
4.CONSTRUCTION.
• THIS ACTIVITY COMBINES CODE GENERATION (EITHER MANUAL OR
AUTOMATED) AND THE TESTING THAT IS REQUIRED TO UNCOVER ERRORS
IN THE CODE.
5.DEPLOYMENT.
• THE SOFTWARE (AS A COMPLETE ENTITY OR AS A PARTIALLY COMPLETED
INCREMENT) IS DELIVERED TO THE CUSTOMER WHO EVALUATES THE
DELIVERED PRODUCT AND PROVIDES FEEDBACK BASED ON THE EVALUATION
• SOFTWARE ENGINEERING PROCESS FRAMEWORK ACTIVITIES ARE
COMPLEMENTED BY A NUM BER OF UMBRELLA ACTIVITIES.
• SOFTWARE PROJECT TRACKING AND CONTROL—ALLOWS THE
SOFTWARE TEAM TO ASSESS PROGRESS AGAINST THE PROJECT
PLAN AND TAKE ANY NECESSARY ACTION TO MAINTAIN THE
SCHEDULE.
• RISK MANAGEMENT—ASSESSES RISKS THAT MAY AFFECT THE
OUTCOME OF THE PROJECT OR THE QUALITY OF THE PRODUCT.
• SOFTWARE QUALITY ASSURANCE—DEFINES AND CONDUCTS THE
ACTIVITIES REQUIRED TO ENSURE SOFTWARE QUALITY.
• TECHNICAL REVIEWS—ASSESSES SOFTWARE ENGINEERING WORK
PRODUCTS IN AN EFFORT TO UNCOVER AND REMOVE ERRORS
BEFORE THEY ARE PROPAGATED TO THE NEXT ACTIVITY.
• MEASUREMENT—DEFINES AND COLLECTS PROCESS, PROJECT,
AND PRODUCT MEASURES THAT ASSIST THE TEAM IN
DELIVERING SOFTWARE THAT MEETS STAKEHOLDERS’ NEEDS;
CAN BE USED IN CONJUNCTION WITH ALL OTHER FRAMEWORK
AND UMBRELLA ACTIVITIES.
• SOFTWARE CONFIGURATION MANAGEMENT—MANAGES THE
EFFECTS OF CHANGE THROUGHOUT THE SOFTWARE PROCESS.
• REUSABILITY MANAGEMENT—DEFINES CRITERIA FOR WORK
PRODUCT REUSE (INCLUDING SOFTWARE COMPONENTS) AND
ESTABLISHES MECHANISMS TO ACHIEVE REUSABLE
COMPONENTS.
• WORK PRODUCT PREPARATION AND PRODUCTION—
ENCOMPASSES THE ACTIVITIES REQUIRED TO CREATE WORK
• A PROCESS ADOPTED FOR ONE PROJECT MIGHT BE
SIGNIFICANTLY DIFFERENT THAN A PROCESS ADOPTED FOR
ANOTHER PROJECT. THE DIFFERENCES ARE :
• OVERALL FLOW OF ACTIVITIES, ACTIONS, AND TASKS AND THE
INTERDEPENDENCIES AMONG THEM
• DEGREE TO WHICH ACTIONS AND TASKS ARE DEFINED WITHIN
EACH FRAMEWORK ACTIVITY
• DEGREE TO WHICH WORK PRODUCTS ARE IDENTIFIED AND
REQUIRED
• MANNER IN WHICH QUALITY ASSURANCE ACTIVITIES ARE APPLIED
• MANNER IN WHICH PROJECT TRACKING AND CONTROL ACTIVITIES
ARE APPLIED
• OVERALL DEGREE OF DETAIL AND RIGOR WITH WHICH THE
PROCESS IS DESCRIBED
• DEGREE TO WHICH THE CUSTOMER AND OTHER
STAKEHOLDERS ARE INVOLVED WITH THE PROJECT
• LEVEL OF AUTONOMY GIVEN TO THE SOFTWARE TEAM
• DEGREE TO WHICH TEAM ORGANIZATION AND ROLES ARE
PRESCRIBED
 SOFTWARE ENGINEERING PRACTICE
• THE ESSENCE OF PRACTICE:
1. UNDERSTAND THE PROBLEM (COMMUNICATION AND
ANALYSIS).
2. PLAN A SOLUTION (MODELING AND SOFTWARE DESIGN).
3. CARRY OUT THE PLAN (CODE GENERATION).
4. EXAMINE THE RESULT FOR ACCURACY (TESTING AND QUALITY
ASSURANCE)
• UNDERSTAND THE PROBLEM.
• WE LISTEN FOR A FEW SECONDS AND THEN THINK, OH YEAH, I
UNDERSTAND, LET’S GET ON WITH SOLVING THIS THING. UNFORTUNATELY,
UNDERSTANDING ISN’T ALWAYS THAT EASY.
• IT’S WORTH SPENDING A LITTLE TIME ANSWERING A FEW SIMPLE
QUESTIONS:
• WHO HAS A STAKE IN THE SOLUTION TO THE PROBLEM? THAT IS, WHO ARE
THE STAKE HOLDERS?
• WHAT ARE THE UNKNOWNS? WHAT DATA, FUNCTIONS, AND FEATURES
ARE REQUIRED TO PROPERLY SOLVE THE PROBLEM?
• CAN THE PROBLEM BE COMPARTMENTALIZED? IS IT POSSIBLE TO
REPRESENT SMALLER PROBLEMS THAT MAY BE EASIER TO UNDERSTAND?
• CAN THE PROBLEM BE REPRESENTED GRAPHICALLY? CAN AN ANALYSIS
MODEL BE CREATED?
• PLAN THE SOLUTION.
• AFTER UNDERSTANDING THE PROBLEM, BEFORE CODING, SLOW DOWN JUST
A BIT AND DO A LITTLE DESIGN:
• • HAVE YOU SEEN SIMILAR PROBLEMS BEFORE? ARE THERE PATTERNS
THAT ARE RECOGNIZ ABLE IN A POTENTIAL SOLUTION? IS THERE
EXISTING SOFTWARE THAT IMPLEMENTS THE DATA, FUNCTIONS, AND
FEATURES THAT ARE REQUIRED?
• HAS A SIMILAR PROBLEM BEEN SOLVED? IF SO, ARE ELEMENTS OF THE
SOLUTION REUSABLE?
• CAN SUB PROBLEMS BE DEFINED? IF SO, ARE SOLUTIONS READILY APPARENT
FOR THE SUB PROBLEMS?
• CAN YOU REPRESENT A SOLUTION IN A MANNER THAT LEADS TO EFFECTIVE
IMPLEMENTATION? CAN A DESIGN MODEL BE CREATED?
• CARRY OUT THE PLAN.
• THE DESIGN YOU’VE CREATED SERVES AS A ROAD MAP FOR
THE SYSTEM YOU WANT TO BUILD.
• THERE MAY BE UNEXPECTED DETOURS, AND IT’S POSSIBLE THAT
YOU’LL DISCOVER AN EVEN BETTER ROUTE AS YOU GO, BUT THE
“PLAN” WILL ALLOW YOU TO PROCEED WITHOUT GETTING LOST.
• DOES THE SOLUTION CONFORM TO THE PLAN? IS SOURCE
CODE TRACEABLE TO THE DESIGN MODEL?
• IS EACH COMPONENT PART OF THE SOLUTION PROVABLY
CORRECT? HAVE THE DESIGN AND CODE BEEN REVIEWED, OR
BETTER, HAVE CORRECTNESS PROOFS BEEN APPLIED TO THE
ALGORITHM?
• EXAMINE THE RESULT.
• YOU CAN’T BE SURE THAT YOUR SOLUTION IS PERFECT, BUT YOU
CAN BE SURE THAT YOU’VE DESIGNED A SUFFICIENT NUMBER
OF TESTS TO UNCOVER AS MANY ERRORS AS POSSIBLE.
• IS IT POSSIBLE TO TEST EACH COMPONENT PART OF THE
SOLUTION? HAS A REASONABLE TESTING STRATEGY BEEN
IMPLEMENTED?
• DOES THE SOLUTION PRODUCE RESULTS THAT CONFORM TO
THE DATA, FUNCTIONS, AND FEATURES THAT ARE REQUIRED?
HAS THE SOFTWARE BEEN VALIDATED AGAINST ALL
STAKEHOLDER REQUIREMENTS?
• DAVID HOOKER HAS PROPOSED SEVEN PRINCIPLES THAT
FOCUS ON SOFTWARE ENGINEERING PRACTICE AS A WHOLE.
THEY ARE:
• THE FIRST PRINCIPLE: THE REASON IT ALL EXISTS
• A SOFTWARE SYSTEM EXISTS FOR ONE REASON:
• TO PROVIDE VALUE TO ITS USERS. ALL DECISIONS SHOULD BE
MADE WITH THIS IN MIND.
• BEFORE SPECIFYING A SYSTEM REQUIREMENT, BEFORE NOTING
A PIECE OF SYSTEM FUNCTIONALITY, BEFORE DETERMINING THE
HARD WARE PLATFORMS OR DEVELOPMENT PROCESSES, ASK
YOURSELF QUESTIONS SUCH AS:
• “DOES THIS ADD REAL VALUE TO THE SYSTEM?” IF THE ANSWER
IS “NO,” DON’T DO IT.
• THE SECOND PRINCIPLE: (KEEP IT SIMPLE, STUPID!)
• SOFTWARE DESIGN IS NOT A HAPHAZARD PROCESS.
• THERE ARE MANY FACTORS TO CONSIDER IN ANY DESIGN
EFFORT.
• ALL DESIGN SHOULD BE AS SIMPLE AS POSSIBLE, BUT NO
SIMPLER. THIS FACILITATES HAVING A MORE EASILY UNDERSTOOD
AND EASILY MAINTAINED SYSTEM. THIS IS NOT TO SAY THAT
FEATURES, EVEN INTERNAL FEATURES, SHOULD BE DISCARDED IN
THE NAME OF SIMPLICITY.
• INDEED, THE MORE ELEGANT DESIGNS ARE USUALLY THE MORE
SIMPLE ONES.
• SIMPLE ALSO DOES NOT MEAN “QUICK AND DIRTY.” IN FACT, IT
OFTEN TAKES A LOT OF THOUGHT AND WORK OVER MULTIPLE
• THE THIRD PRINCIPLE: MAINTAIN THE VISION
• A CLEAR VISION IS ESSENTIAL TO THE SUCCESS OF A SOFTWARE
PROJECT. WITHOUT ONE, A PROJECT ALMOST UNFAILINGLY ENDS
UP BEING “OF TWO [OR MORE] MINDS” ABOUT ITSELF.
• COMPROMISING THE ARCHITECTURAL VISION OF A
SOFTWARE SYSTEM WEAKENS AND WILL EVENTUALLY BREAK
EVEN THE WELL-DESIGNED SYSTEMS.
• HAVING AN EMPOWERED ARCHITECT WHO CAN HOLD THE
VISION AND ENFORCE COMPLIANCE HELPS ENSURE A VERY
SUCCESSFUL SOFTWARE PROJECT
• THE FOURTH PRINCIPLE: WHAT YOU PRODUCE, OTHERS WILL CONSUME
• SELDOM IS AN INDUSTRIAL-STRENGTH SOFTWARE SYSTEM CONSTRUCTED AND
USED IN A VACUUM.
• IN SOME WAY OR OTHER, SOMEONE ELSE WILL USE, MAINTAIN, DOCUMENT, OR
OTHERWISE DEPEND ON BEING ABLE TO UNDERSTAND YOUR SYSTEM.
• SO, ALWAYS SPECIFY, DESIGN, AND IMPLEMENT KNOWING SOMEONE
ELSE WILL HAVE TO UNDERSTAND WHAT YOU ARE DOING.
• THE AUDIENCE FOR ANY PRODUCT OF SOFTWARE DEVELOPMENT IS
POTENTIALLY LARGE. SPECIFY WITH AN EYE TO THE USERS. DESIGN, KEEPING
THE IMPLEMENTERS IN MIND.
• CODE WITH CONCERN FOR THOSE THAT MUST MAINTAIN AND EXTEND THE
SYSTEM.
• SOMEONE MAY HAVE TO DEBUG THE CODE YOU WRITE, AND THAT MAKES THEM
A USER OF YOUR CODE. MAKING THEIR JOB EASIER ADDS VALUE TO THE SYSTEM
• THE FIFTH PRINCIPLE: BE OPEN TO THE FUTURE
• A SYSTEM WITH A LONG LIFETIME HAS MORE VALUE.
• IN TODAY’S COMPUTING ENVIRONMENTS, WHERE SPECIFICATIONS CHANGE
ON A MOMENT’S NOTICE AND HARDWARE PLATFORMS ARE OBSOLETE JUST A
FEW MONTHS OLD, SOFTWARE LIFETIMES ARE TYPICALLY MEASURED IN
MONTHS INSTEAD OF YEARS. HOWEVER, TRUE “INDUSTRIAL-STRENGTH”
SOFTWARE SYSTEMS MUST ENDURE FAR LONGER.
• TO DO THIS SUCCESSFULLY, THESE SYSTEMS MUST BE READY TO ADAPT TO
THESE AND OTHER CHANGES. SYSTEMS THAT DO THIS SUCCESSFULLY ARE
THOSE THAT HAVE BEEN DESIGNED THIS WAY FROM THE START.
• NEVER DESIGN YOURSELF INTO A CORNER. ALWAYS ASK “WHAT IF,” AND
PREPARE FOR ALL POSSIBLE ANSWERS BY CREATING SYSTEMS THAT SOLVE
THE GENERAL PROBLEM, NOT JUST THE SPECIFIC ONE.
• THIS COULD VERY POSSIBLY LEAD TO THE REUSE OF AN ENTIRE SYSTEM
• THE SIXTH PRINCIPLE: PLAN AHEAD FOR REUSE
• REUSE SAVES TIME AND EFFORT.
• ACHIEVING A HIGH LEVEL OF REUSE IS ARGUABLY THE HARDEST GOAL TO
ACCOMPLISH IN DEVELOPING A SOFTWARE SYSTEM.
• THE REUSE OF CODE AND DESIGNS HAS BEEN PROCLAIMED AS A MAJOR
BENEFIT OF USING OBJECT-ORIENTED TECHNOLOGIES.
• HOWEVER, THE RETURN ON THIS INVESTMENT IS NOT AUTOMATIC. TO
LEVERAGE THE REUSE POSSIBILITIES THAT OBJECT-ORIENTED [OR
CONVENTIONAL] PROGRAMMING PROVIDES REQUIRES FORETHOUGHT AND
PLANNING.
• THERE ARE MANY TECHNIQUES TO REALIZE REUSE AT EVERY LEVEL OF THE
SYSTEM DEVELOPMENT PROCESS. . . . PLANNING AHEAD FOR REUSE REDUCES
THE COST AND INCREASES THE VALUE OF BOTH THE REUSABLE
• THE SEVENTH PRINCIPLE: THINK!
• THIS LAST PRINCIPLE IS PROBABLY THE MOST OVERLOOKED.
• PLACING CLEAR, COMPLETE THOUGHT BEFORE ACTION ALMOST ALWAYS
PRODUCES BETTER RESULTS. WHEN YOU THINK ABOUT SOMETHING, YOU ARE
MORE LIKELY TO DO IT RIGHT.
• YOU ALSO GAIN KNOWLEDGE ABOUT HOW TO DO IT RIGHT AGAIN.
• IF YOU DO THINK ABOUT SOMETHING AND STILL DO IT WRONG, IT BE COMES
A VALUABLE EXPERIENCE.
• A SIDE EFFECT OF THINKING IS LEARNING TO RECOGNIZE WHEN YOU
DON’T KNOW SOMETHING, AT WHICH POINT YOU CAN RESEARCH THE
ANSWER.
• WHEN CLEAR THOUGHT HAS GONE INTO A SYSTEM, VALUE COMES OUT.
APPLYING THE FIRST SIX PRINCIPLES REQUIRES INTENSE THOUGHT, FOR
WHICH THE POTENTIAL REWARDS ARE ENORMOUS.
 SOFTWARE MYTHS
• MANAGEMENT MYTHS.
• MYTH:
• WE ALREADY HAVE A BOOK THAT’S FULL OF STANDARDS AND PROCEDURES FOR
BUILDING SOFTWARE. WON’T THAT PROVIDE MY PEOPLE WITH EVERYTHING THEY
NEED TO KNOW?
• REALITY:
• THE BOOK OF STANDARDS MAY VERY WELL EXIST, BUT IS IT USED?
• ARE SOFT WARE PRACTITIONERS AWARE OF ITS EXISTENCE?
• DOES IT REFLECT MODERN SOFTWARE ENGINEERING PRACTICE? IS IT
COMPLETE? IS IT ADAPTABLE?
• IS IT STREAMLINED TO IMPROVE TIME-TO-DELIVERY WHILE STILL MAINTAINING
A FOCUS ON QUALITY?
• IN MANY CASES, THE ANSWER TO ALL OF THESE QUESTIONS IS “NO.”
 SOFTWARE MYTHS
• MANAGEMENT MYTHS.
• MYTH:
• IF WE GET BEHIND SCHEDULE, WE CAN ADD MORE PROGRAMMERS AND CATCH UP
(SOMETIMES CALLED THE “MONGOLIAN HORDE” CONCEPT).
• REALITY:
• SOFTWARE DEVELOPMENT IS NOT A MECHANISTIC PROCESS LIKE MANUFACTUR ING.
• IN THE WORDS OF BROOKS “ADDING PEOPLE TO A LATE SOFT WARE PROJECT MAKES IT
LATER.”
• AT FIRST, THIS STATEMENT MAY SEEM COUNTERINTUITIVE.
• HOWEVER, AS NEW PEOPLE ARE ADDED, PEOPLE WHO WERE WORKING MUST SPEND
TIME EDUCATING THE NEWCOMERS, THEREBY REDUCING THE AMOUNT OF TIME SPENT
ON PRODUCTIVE DEVELOPMENT EFFORT.
• PEOPLE CAN BE ADDED BUT ONLY IN A PLANNED AND WELL COORDINATED MANNER.
 SOFTWARE MYTHS
• MANAGEMENT MYTHS.
• MYTH:
• IF I DECIDE TO OUTSOURCE THE SOFTWARE PROJECT TO A THIRD PARTY, I CAN
JUST RELAX AND LET THAT FIRM BUILD IT.
• REALITY:
• IF AN ORGANIZATION DOES NOT UNDERSTAND HOW TO MANAGE AND
CONTROL SOFTWARE PROJECTS INTERNALLY, IT WILL INVARIABLY STRUGGLE
WHEN IT OUT SOURCES SOFTWARE PROJECTS.
 SOFTWARE MYTHS
• CUSTOMER MYTHS.
• MYTH:
• A GENERAL STATEMENT OF OBJECTIVES IS SUFFICIENT TO BEGIN WRITING
PROGRAMS—WE CAN FILL IN THE DETAILS LATER.
• REALITY:
• ALTHOUGH A COMPREHENSIVE AND STABLE STATEMENT OF REQUIREMENTS IS
NOT ALWAYS POSSIBLE, AN AMBIGUOUS “STATEMENT OF OBJECTIVES” IS A
RECIPE FOR DISASTER.
• UNAMBIGUOUS REQUIREMENTS (USUALLY DERIVED ITERATIVELY) ARE
DEVELOPED ONLY THROUGH EFFECTIVE AND CONTINUOUS COMMUNICATION
BETWEEN CUSTOMER AND DEVELOPER.
 SOFTWARE MYTHS
• CUSTOMER MYTHS.
• MYTH:
• SOFTWARE REQUIREMENTS CONTINUALLY CHANGE, BUT CHANGE CAN BE
EASILY ACCOMMODATED BECAUSE SOFTWARE IS FLEXIBLE.
• REALITY:
• IT IS TRUE THAT SOFTWARE REQUIREMENTS CHANGE, BUT THE IMPACT OF
CHANGE VARIES WITH THE TIME AT WHICH IT IS INTRODUCED.
• WHEN REQUIREMENTS CHANGES ARE REQUESTED EARLY (BEFORE DESIGN OR
CODE HAS BEEN STARTED), THE COST IMPACT IS RELATIVELY SMALL.
• HOWEVER, AS TIME PASSES, THE COST IMPACT GROWS RAPIDLY—RESOURCES
HAVE BEEN COMMIT TED, A DESIGN FRAMEWORK HAS BEEN ESTABLISHED,
AND CHANGE CAN CAUSE UPHEAVAL THAT REQUIRES ADDITIONAL RESOURCES
AND MAJOR DESIGN MODIFICATION
 SOFTWARE MYTHS
• PRACTITIONER’S MYTHS.
• MYTH:
• ONCE WE WRITE THE PROGRAM AND GET IT TO WORK, OUR JOB IS DONE.
• REALITY:
• SOMEONE ONCE SAID THAT “THE SOONER YOU BEGIN ‘WRITING CODE,’ THE
LONGER IT’LL TAKE YOU TO GET DONE.”
• INDUSTRY DATA INDICATE THAT BETWEEN 60 AND 80 PERCENT OF ALL
EFFORT EXPENDED ON SOFTWARE WILL BE EX PENDED AFTER IT IS
DELIVERED TO THE CUSTOMER FOR THE FIRST TIME.
 SOFTWARE MYTHS
• PRACTITIONER’S MYTHS.
• MYTH:
• UNTIL I GET THE PROGRAM “RUNNING” I HAVE NO WAY OF ASSESSING ITS
QUALITY.
• REALITY:
• ONE OF THE MOST EFFECTIVE SOFTWARE QUALITY ASSURANCE MECHANISMS
CAN BE APPLIED FROM THE INCEPTION OF A PROJECT—THE TECHNICAL
REVIEW.
• SOFTWARE REVIEWS ARE A “QUALITY FILTER” THAT HAVE BEEN FOUND
TO BE MORE EFFECTIVE THAN TESTING FOR FINDING CERTAIN CLASSES OF
SOFTWARE DEFECTS.
 SOFTWARE MYTHS
• PRACTITIONER’S MYTHS.
• MYTH:
• THE ONLY DELIVERABLE WORK PRODUCT FOR A SUCCESSFUL PROJECT IS THE
WORKING PROGRAM
• REALITY:
• A WORKING PROGRAM IS ONLY ONE PART OF A SOFTWARE CONFIGURATION
THAT INCLUDES MANY ELEMENTS.
• A VARIETY OF WORK PRODUCTS (E.G., MODELS, DOCUMENTS, PLANS) PROVIDE
A FOUNDATION FOR SUCCESSFUL ENGINEERING AND, MORE IMPORTANT,
GUIDANCE FOR SOFTWARE SUPPORT.
 SOFTWARE MYTHS
• PRACTITIONER’S MYTHS.
• MYTH:
• SOFTWARE ENGINEERING WILL MAKE US CREATE VOLUMINOUS AND
UNNECESSARY DOCUMENTATION AND WILL INVARIABLY SLOW US DOWN
• REALITY:
• SOFTWARE ENGINEERING IS NOT ABOUT CREATING DOCUMENTS.
• IT IS ABOUT CREATING A QUALITY PRODUCT. BETTER QUALITY LEADS TO
REDUCED REWORK.
• AND REDUCED REWORK RESULTS IN FASTER DELIVERY TIMES
 A GENERIC PROCESS MODEL
• A PROCESS WAS DEFINED
• AS A COLLECTION OF WORK ACTIVITIES, ACTIONS, AND TASKS
• THAT ARE PERFORMED WHEN SOME WORK PRODUCT IS TO BE
CREATED.
• EACH OF THESE ACTIVITIES, ACTIONS, AND TASKS RESIDE WITHIN
A FRAMEWORK THAT DEFINES THEIR RELATIONSHIP WITH THE
PROCESS AND WITH ONE ANOTHER.
• THIS ASPECT—CALLED PROCESS FLOW—DESCRIBES HOW THE
FRAME WORK ACTIVITIES AND THE ACTIONS AND TASKS THAT
OCCUR WITHIN EACH FRAMEWORK
• A LINEAR PROCESS FLOW EXECUTES EACH OF THE FIVE FRAMEWORK
ACTIVITIES IN SEQUENCE, BEGINNING WITH COMMUNICATION AND
CULMINATING WITH DEPLOYMENT
• AN ITERATIVE PROCESS FLOW REPEATS ONE OR MORE OF THE ACTIVITIES
BEFORE PROCEEDING TO THE NEXT
• AN EVOLUTIONARY PROCESS FLOW EXECUTES THE ACTIVITIES IN A
“CIRCULAR” MANNER. EACH CIRCUIT THROUGH THE FIVE ACTIVITIES LEADS TO
A MORE COMPLETE VERSION OF THE SOFTWARE
• A PARALLEL PROCESS FLOW EXECUTES ONE OR MORE ACTIVITIES IN
PARALLEL WITH OTHER ACTIVITIES (E.G., MODELING FOR ONE ASPECT OF THE
SOFTWARE MIGHT BE EXECUTED IN PARALLEL WITH CONSTRUCTION OF
ANOTHER ASPECT OF THE SOFTWARE)
• DEFINING A FRAMEWORK ACTIVITY:
• WHAT ACTIONS ARE APPROPRIATE FOR A FRAMEWORK ACTIVITY,
• GIVEN THE NATURE OF THE PROBLEM TO BE SOLVED,
• THE CHARACTERISTICS OF THE PEOPLE DOING THE WORK,
• AND THE STAKEHOLDERS WHO ARE SPONSOR ING THE PROJECT
• FOR A SMALL SOFTWARE PROJECT REQUESTED BY ONE PERSON (AT A
REMOTE LOCATION) WITH SIMPLE, STRAIGHTFORWARD REQUIREMENTS,
• 1. MAKE CONTACT WITH STAKEHOLDER VIA TELEPHONE.
• 2. DISCUSS REQUIREMENTS AND TAKE NOTES
• 3. ORGANIZE NOTES INTO A BRIEF WRITTEN STATEMENT OF
REQUIREMENTS.
• 4. E-MAIL TO STAKEHOLDER FOR REVIEW AND APPROVAL
• IDENTIFYING A TASK SET
• , EACH SOFTWARE ENGINEERING ACTION CAN BE REPRESENTED BY A NUMBER
OF DIFFERENT TASK SETS—
• EACH A COLLECTION OF SOFTWARE ENGINEERING WORK TASKS, RELATED
WORK PRODUCTS, QUALITY ASSURANCE POINTS, AND PROJECT MILESTONES.
• YOU SHOULD CHOOSE A TASK SET THAT BEST ACCOMMODATES THE NEEDS OF
THE PROJECT AND THE CHARACTERISTICS OF YOUR TEAM.
• THIS IMPLIES THAT A SOFTWARE ENGINEERING ACTION CAN BE ADAPTED TO
THE SPECIFIC NEEDS OF THE SOFTWARE PROJECT AND THE CHARACTERISTICS
OF THE PROJECT TEAM.
• PROCESS PATTERNS
• A PROCESS PATTERN DESCRIBES A PROCESS-RELATED PROBLEM THAT IS
ENCOUNTERED DURING SOFTWARE ENGINEERING WORK,
• IDENTIFIES THE ENVIRONMENT IN WHICH THE PROBLEM HAS BEEN
ENCOUNTERED,
• AND SUGGESTS ONE OR MORE PROVEN SOLUTIONS TO THE PROBLEM.
• STATED IN MORE GENERAL TERMS, A PROCESS PATTERN PROVIDES YOU WITH A
TEMPLATE .A CONSISTENT METHOD FOR DESCRIBING PROBLEM
SOLUTIONS WITHIN THE CONTEXT OF THE SOFTWARE PROCESS.
• BY COMBINING PATTERNS, A SOFTWARE TEAM CAN SOLVE PROBLEMS AND
CONSTRUCT A PROCESS THAT BEST MEETS THE NEEDS OF A PROJECT.
• AMBLER HAS PROPOSED A TEMPLATE FOR DESCRIBING A PROCESS
PATTERN:
• PATTERN NAME:
• THE PATTERN IS GIVEN A MEANINGFUL NAME DESCRIBING IT WITHIN THE CONTEXT
OF THE SOFTWARE PROCESS (E.G., TECHNICAL REVIEWS).

• FORCES.
• THE ENVIRONMENT IN WHICH THE PATTERN IS ENCOUNTERED AND THE ISSUES
THAT MAKE THE PROBLEM VISIBLE AND MAY AFFECT ITS SOLUTION. .
• TYPE.
• 1. STAGE PATTERN
• —DEFINES A PROBLEM ASSOCIATED WITH A FRAMEWORK
ACTIVITY FOR THE PROCESS. SINCE A FRAMEWORK ACTIVITY
ENCOMPASSES MULTIPLE ACTIONS AND WORK TASKS, A STAGE PATTERN
INCORPORATES MULTIPLE TASK PATTERNS THAT ARE RELEVANT TO THE
STAGE (FRAMEWORK ACTIVITY). AN EXAMPLE OF A STAGE PATTERN
MIGHT BE ESTABLISHING COMMUNICATION. THIS PATTERN WOULD
INCORPORATE THE TASK PATTERN REQUIREMENTS GATHERING AND
OTHERS.
• 2. TASK PATTERN
• —DEFINES A PROBLEM ASSOCIATED WITH A SOFTWARE
ENGINEERING ACTION OR WORK TASK AND RELEVANT TO SUCCESSFUL
SOFTWARE ENGINEERING PRACTICE (E.G., REQUIREMENTS GATHERING
IS A TASK PATTERN).
• 3. PHASE PATTERN
• INITIAL CONTEXT.
• DESCRIBES THE CONDITIONS UNDER WHICH THE PATTERN APPLIES. PRIOR TO
THE INITIATION OF THE PATTERN:
• (1) WHAT ORGANIZATIONAL OR TEAM-RELATED ACTIVITIES HAVE ALREADY
OCCURRED?
• (2) WHAT IS THE ENTRY STATE FOR THE PROCESS?
• (3) WHAT SOFTWARE ENGINEERING INFORMATION OR PROJECT
INFORMATION ALREADY EXISTS?
• THE PLANNING PATTERN (A STAGE PATTERN) REQUIRES THAT
(1) CUSTOMERS AND SOFTWARE ENGINEERS HAVE ESTABLISHED A
COLLABORATIVE COMMUNI CATION;
(2) SUCCESSFUL COMPLETION OF A NUMBER OF TASK PATTERNS [SPECIFIED]
FOR THE COMMUNICATION PATTERN HAS OCCURRED; AND
(3) THE PROJECT SCOPE, BASIC BUSINESS REQUIREMENTS, AND PROJECT
CONSTRAINTS ARE KNOWN.
• PROBLEM.
• THE SPECIFIC PROBLEM TO BE SOLVED BY THE PATTERN
SOLUTION.
• DESCRIBES HOW TO IMPLEMENT THE PATTERN
SUCCESSFULLY.
• THIS SECTION DESCRIBES HOW THE INITIAL STATE OF THE
PROCESS (THAT EXISTS BEFORE THE PAT TERN IS
IMPLEMENTED) IS MODIFIED AS A CONSEQUENCE OF THE
INITIATION OF THE PATTERN.
• IT ALSO DESCRIBES HOW SOFTWARE ENGINEERING
INFORMATION OR PROJECT INFORMATION THAT IS AVAILABLE
BEFORE THE INITIATION OF THE PATTERN IS TRANSFORMED AS
A CONSEQUENCE OF THE SUCCESSFUL EXECUTION OF THE
PATTERN.
• RESULTING CONTEXT.
• DESCRIBES THE CONDITIONS THAT WILL RESULT ONCE THE PAT TERN HAS BEEN
SUCCESSFULLY IMPLEMENTED.
• UPON COMPLETION OF THE PATTERN:
• (1) WHAT ORGANIZATIONAL OR TEAM-RELATED ACTIVITIES MUST HAVE
OCCURRED?
• (2) WHAT IS THE EXIT STATE FOR THE PROCESS?
• (3) WHAT SOFTWARE ENGINEERING INFORMATION OR PROJECT INFORMATION
HAS BEEN DEVELOPED? RELATED PATTERNS.
• PROVIDE A LIST OF ALL PROCESS PATTERNS THAT ARE DIRECTLY RELATED TO
THIS ONE. THIS MAY BE REPRESENTED AS A HIERARCHY OR IN SOME OTHER
DIAGRAMMATIC FORM. FOR EXAMPLE, THE STAGE PATTERN COMMUNICATION
ENCOMPASSES THE TASK PATTERNS: PROJECTTEAM, COLLABORATIVEGUIDELINES,
SCOPEISOLATION, REQUIREMENTSGATHERING, CONSTRAINTDESCRIPTION, AND
SCENARIOCREATION
• DIFFERENT APPROACHES TO SOFTWARE PROCESS
ASSESSMENT AND IMPROVEMENT

• ISO 9001:2000 FOR SOFTWARE—A GENERIC STANDARD THAT

APPLIES TO ANY OR GANIZATION THAT WANTS TO IMPROVE THE
OVERALL QUALITY OF THE PRODUCTS, SYSTEMS, OR SERVICES
THAT IT PROVIDES. THEREFORE, THE STANDARD IS DIRECTLY
APPLICABLE TO SOFTWARE ORGANIZATIONS AND COMPANIES
• STANDARD CMMI(CAPABILTY MATURITY MODEL)
ASSESSMENT METHOD FOR PROCESS IMPROVEMENT
(SCAMPI)—PROVIDES A FIVE-STEP PROCESS ASSESSMENT MODEL
THAT INCORPORATES FIVE PHASES: INITIATING, DIAGNOSING,
ESTABLISHING, ACTING, AND LEARNING. THE SCAMPI METHOD USES
THE SEI CMMI AS THE BASIS FOR ASSESSMENT
• CMM-BASED APPRAISAL FOR INTERNAL PROCESS
IMPROVEMENT (CBA IPI)-PROVIDES A DIAGNOSTIC TECHNIQUE
FOR ASSESSING THE RELATIVE MATURITY OF A SOFTWARE
ORGANIZATION; USES THE SEI CMM AS THE BASIS FOR THE
ASSESSMENT
• SPICE (ISO/IEC15504)(SOFTWARE PROCESS IMPROVEMENT
AND CAPABILITY DETERMINATION)—A STANDARD THAT DEFINES
A SET OF REQUIREMENTS FOR SOFTWARE PROCESS ASSESSMENT.
THE INTENT OF THE STANDARD IS TO ASSIST ORGANI ZATIONS IN
DEVELOPING AN OBJECTIVE EVALUATION OF THE EFFICACY OF ANY
DEFINED SOFTWARE PROCESS

• ISO –INTERNATIONAL ORGANISATION FOR STANDARD

• IEC-INTERNATIONAL ELCTRO TECHNICAL COMMISSION
 PRESCRIPTIVE PROCESS MODELS
• PROPOSED TO BRING ORDER TO THE CHAOS OF SOFTWARE DEVELOPMENT.
• THESE TRADITIONAL MODELS HAVE BROUGHT A CERTAIN AMOUNT OF USEFUL
STRUCTURE TO SOFTWARE ENGINEERING WORK AND HAVE PROVIDED A
REASONABLY EFFECTIVE ROAD MAP FOR SOFTWARE TEAMS.
• THE WATERFALL MODEL
• WHEN THE REQUIREMENTS FOR A PROBLEM ARE WELL UNDERSTOOD—WHEN
WORK FLOWS FROM COMMUNICATION THROUGH DEPLOYMENT IN A REASONABLY
LINEAR FASH ION.
• THE WATERFALL MODEL, SOMETIMES CALLED THE CLASSIC LIFE CYCLE,
SUGGESTS A SYSTEMATIC, SEQUENTIAL APPROACH TO SOFTWARE
DEVELOPMENT THAT BEGINS WITH CUSTOMER SPECIFICA TION OF
REQUIREMENTS AND PROGRESSES THROUGH PLANNING, MODELING,
CONSTRUCTION, AND DEPLOYMENT, CULMINATING IN ONGOING SUPPORT OF THE
COMPLETED SOFTWARE
 PRESCRIPTIVE PROCESS MODELS
• PROPOSED TO BRING ORDER TO THE CHAOS OF SOFTWARE DEVELOPMENT.
• THESE TRADITIONAL MODELS HAVE BROUGHT A CERTAIN AMOUNT OF USEFUL
STRUCTURE TO SOFTWARE ENGINEERING WORK AND HAVE PROVIDED A
REASONABLY EFFECTIVE ROAD MAP FOR SOFTWARE TEAMS.
• THE WATERFALL MODEL
• WHEN THE REQUIREMENTS FOR A PROBLEM ARE WELL UNDERSTOOD—WHEN
WORK FLOWS FROM COMMUNICATION THROUGH DEPLOYMENT IN A REASONABLY
LINEAR FASH ION.
• THE WATERFALL MODEL, SOMETIMES CALLED THE CLASSIC LIFE CYCLE,
SUGGESTS A SYSTEMATIC, SEQUENTIAL APPROACH TO SOFTWARE
DEVELOPMENT THAT BEGINS WITH CUSTOMER SPECIFICA TION OF
REQUIREMENTS AND PROGRESSES THROUGH PLANNING, MODELING,
CONSTRUCTION, AND DEPLOYMENT, CULMINATING IN ONGOING SUPPORT OF THE
COMPLETED SOFTWARE
PRESCRIPTIVE PROCESS MODELS
 PRESCRIPTIVE PROCESS MODELS
• A VARIATION IN THE REPRESENTATION OF THE WATERFALL MODEL IS CALLED
THE V-MODEL.
• V-MODEL:
• THE V-MODEL DEPICTS THE RELATIONSHIP OF QUALITY
ASSURANCE ACTIONS TO THE ACTIONS ASSOCIATED WITH
COMMUNICATION, MODELING, AND EARLY CONSTRUCTION ACTIVITIES
• AS A SOFTWARE TEAM MOVES DOWN THE LEFT SIDE OF THE V,
BASIC PROBLEM REQUIREMENTS ARE REFINED INTO
PROGRESSIVELY MORE DETAILED AND TECHNICAL REPRESENTATIONS
OF THE PROBLEM AND ITS SOLUTION.
• ONCE CODE HAS BEEN GENERATED, THE TEAM MOVES UP THE RIGHT
SIDE OF THE V, ESSENTIALLY PERFORMING A SERIES OF TESTS
(QUALITY ASSURANCE ACTIONS) THAT VALIDATE EACH OF THE
MODELS CREATED AS THE TEAM MOVED DOWN THE LEFT SIDE
• THE PROBLEMS THAT ARE SOMETIMES ENCOUNTERED
WHEN THE WATERFALL MODEL IS APPLIED ARE:
• 1. REAL PROJECTS RARELY FOLLOW THE SEQUENTIAL
FLOW THAT THE MODEL PROPOSES. ALTHOUGH THE LINEAR
MODEL CAN ACCOMMODATE ITERATION, IT DOES SO INDIRECTLY.
AS A RESULT, CHANGES CAN CAUSE CONFUSION AS THE
PROJECT TEAM PROCEEDS.
• 2. IT IS OFTEN DIFFICULT FOR THE CUSTOMER TO STATE
ALL REQUIREMENTS EXPLICITLY. THE WATERFALL MODEL
REQUIRES THIS AND HAS DIFFICULTY ACCOMMODATING THE
NATURAL UNCERTAINTY THAT EXISTS AT THE BEGINNING OF
MANY PROJECTS.
• 3. THE CUSTOMER MUST HAVE PATIENCE. A WORKING
VERSION OF THE PROGRAM(S) WILL NOT BE AVAILABLE
• INCREMENTAL PROCESS MODELS:
• INITIAL SOFTWARE REQUIREMENTS ARE REASONABLY WELL
DEFINED, BUT THE OVERALL SCOPE OF THE DEVELOPMENT
EFFORT PRECLUDES A PURELY LINEAR PROCESS.
• A COMPELLING NEED TO PROVIDE A LIMITED SET OF SOFT
WARE FUNCTIONALITY TO USERS QUICKLY AND THEN
REFINE AND EXPAND ON THAT FUNCTIONALITY IN LATER
SOFTWARE RELEASES.
• IN SUCH CASES, YOU CAN CHOOSE A PROCESS MODEL THAT IS
DESIGNED TO PRODUCE THE SOFTWARE IN INCREMENTS.
• THE INCREMENTAL MODEL COMBINES ELEMENTS OF LINEAR
AND PARALLEL PROCESS FLOWS
• FOR EXAMPLE, WORD-PROCESSING SOFTWARE
DEVELOPED USING THE INCREMENTAL PARADIGM
MIGHT DELIVER BASIC FILE MANAGEMENT, EDITING,
AND DOCUMENT PRODUCTION FUNCTIONS IN THE
FIRST INCREMENT;
• MORE SOPHISTICATED EDITING AND DOCUMENT
PRODUCTION CAPABILITIES IN THE SECOND
INCREMENT;
• SPELLING AND GRAMMAR CHECKING IN THE THIRD
INCREMENT;
WHEN AN INCREMENTAL MODEL IS USED,
• THE FIRST INCREMENT IS OFTEN A CORE PRODUCT.
• THAT IS, BASIC REQUIREMENTS ARE ADDRESSED BUT MANY
SUPPLEMENTARY FEATURES (SOME KNOWN, OTHERS UNKNOWN)
REMAIN UNDELIVERED.
• THE CORE PRODUCT IS USED BY THE CUSTOMER (OR
UNDERGOES DETAILED EVALUATION).
• AS A RESULT OF USE AND/OR EVALUATION, A PLAN IS
DEVELOPED FOR THE NEXT INCREMENT.
• THE PLAN ADDRESSES THE MODIFICATION OF THE CORE
PRODUCT TO BETTER MEET THE NEEDS OF THE CUSTOMER AND
THE DELIVERY OF ADDITIONAL FEATURES AND FUNCTIONALITY.
• THIS PROCESS IS REPEATED FOLLOWING THE DELIVERY OF
INCREMENTAL DEVELOPMENT IS PARTICULARLY USEFUL WHEN
STAFFING IS UNAVAILABLE FOR A COMPLETE IMPLEMENTATION
BY THE BUSINESS DEADLINE THAT HAS BEEN ESTABLISHED FOR
THE PROJECT.
EARLY INCREMENTS CAN BE IMPLEMENTED WITH FEWER
PEOPLE.
IF THE CORE PRODUCT IS WELL RECEIVED, THEN ADDITIONAL
STAFF (IF REQUIRED) CAN BE ADDED TO IMPLEMENT THE NEXT
INCREMENT.
IN ADDITION, INCREMENTS CAN BE PLANNED TO MANAGE
TECHNICAL RISKS.
 EVOLUTIONARY PROCESS MODELS

• SOFTWARE, EVOLVES OVER A PERIOD OF TIME.

• BUSINESS AND PRODUCT REQUIREMENTS OFTEN CHANGE AS
DEVELOPMENT PROCEEDS, MAKING A STRAIGHT LINE PATH TO AN END
PRODUCT UNREALISTIC;
• TIGHT MARKET DEADLINES MAKE COMPLETION OF A COMPRE HENSIVE
SOFTWARE PRODUCT IMPOSSIBLE, BUT A LIMITED VERSION MUST BE
INTRODUCED TO MEET COMPETITIVE OR BUSINESS PRESSURE;
• A SET OF CORE PRODUCT OR SYSTEM REQUIREMENTS IS WELL
UNDERSTOOD BUT THE DETAILS OF PRODUCT OR SYSTEM EXTENSIONS HAVE
YET TO BE DEFINED. IN THESE AND SIMILAR SITUATIONS,
• YOU NEED A PROCESS MODEL THAT HAS BEEN EXPLICITLY DESIGNED TO
ACCOMMODATE A PRODUCT THAT EVOLVES OVER TIME. EVOLUTIONARY
MODELS ARE ITERATIVE.
1.PROTOTYPING:
• A CUSTOMER DEFINES A SET OF GENERAL OBJECTIVES FOR SOFTWARE, BUT
DOES NOT IDENTIFY DETAILED REQUIREMENTS FOR FUNCTIONS AND
FEATURES.
• THE DEVELOPER MAY BE UNSURE OF 1.THE EFFICIENCY OF AN ALGORITHM,
2.THE ADAPT ABILITY OF AN OPERATING SYSTEM, 3.OR THE FORM THAT
HUMAN-MACHINE INTERACTION SHOULD TAKE.
PROTOTYPING CAN BE PROBLEMATIC FOR THE FOLLOWING
REASONS:
• STAKEHOLDERS SEE WHAT APPEARS TO BE A WORKING VERSION
OF THE SOFTWARE,
• UNAWARE THAT THE PROTOTYPE IS HELD TOGETHER
HAPHAZARDLY,
• UNAWARE THAT IN THE RUSH TO GET IT WORKING YOU
HAVEN’T CONSIDERED OVERALL SOFTWARE QUALITY
OR LONG-TERM MAINTAINABILITY.
• WHEN INFORMED THAT THE PRODUCT MUST BE REBUILT SO
THAT HIGH LEVELS OF QUALITY CAN BE MAINTAINED,
• STAKEHOLDERS CRY FOUL AND DEMAND THAT “A FEW FIXES”
BE APPLIED TO MAKE THE PROTOTYPE A WORKING PRODUCT.
2.THE SPIRAL MODEL.
• AN EVOLUTIONARY SOFTWARE PROCESS MODEL THAT COUPLES
THE ITERATIVE NATURE OF PROTO TYPING
WITH THE CONTROLLED AND SYSTEMATIC ASPECTS OF THE
WATERFALL MODEL.
• THE SPIRAL DEVELOPMENT MODEL IS A RISK-DRIVEN PROCESS MODEL
GENERATOR
• TO GUIDE MULTI-STAKEHOLDER CONCURRENT ENGINEERING OF SOFTWARE
INTENSIVE SYSTEMS.
• TWO MAIN DISTINGUISHING FEATURES.
• ONE IS A CYCLIC APPROACH FOR INCREMENTALLY GROWING A
SYSTEM’S DEGREE OF DEFINITION AND IMPLEMENTATION WHILE
DECREASING ITS DEGREE OF RISK.
• THE OTHER IS A SET OF ANCHOR POINT MILESTONES FOR ENSURING
STAKEHOLDER COMMITMENT TO FEASIBLE AND MUTUALLY SATISFACTORY
THE SPIRAL MODEL.
• THE FIRST CIRCUIT AROUND THE SPIRAL MIGHT RESULT IN THE
DEVELOPMENT OF A PRODUCT SPECIFICATION;
• SUBSEQUENT PASSES AROUND THE SPIRAL MIGHT BE USED TO
DEVELOP A PROTOTYPE
• AND THEN PROGRESSIVELY MORE SOPHISTICATED VERSIONS
OF THE SOFTWARE.
• EACH PASS THROUGH THE PLANNING REGION RESULTS IN
ADJUSTMENTS TO THE PROJECT PLAN.
• CONCURRENT MODEL:
• THE ACTIVITY—MODELING—MAY BE IN ANY ONE OF THE STATES
NOTED AT ANY GIVEN TIME.
• OTHER ACTIVITIES, ACTIONS, OR TASKS (E.G.,
COMMUNICATIONOR CONSTRUCTION) CAN BE REPRESENTED IN
AN ANALOGOUS MANNER.
• ALL SOFTWARE ENGINEERING ACTIVITIES EXIST CONCURRENTLY
BUT RESIDE IN DIFFERENT STATES.
• EARLY IN A PROJECT THE COMMUNICATION ACTIVITY HAS
COMPLETED IT S FIRST ITERATION AND EXISTS IN THE
AWAITING CHANGES STATE.
• THE MODELING ACTIVITY (WHICH EXISTED IN THE INACTIVE
STATE WHILE INITIAL COMMUNICATION WAS COMPLETED, NOW
MAKES A TRANSITION INTO THE UNDER DEVELOPMENT
STATE.
• IF, HOWEVER, THE CUSTOMER INDICATES THAT CHANGES IN
REQUIREMENTS MUST BE MADE,THE MODELING ACTIVITY
MOVES FROM THE UNDER DEVELOPMENT STATE INTO THE
AWAITING CHANGES STATE.
• PROBLEMS WITH EVOLUTIONARY PROCESS MODELS
• THE FIRST CONCERN IS THAT PROTOTYPING POSES A PROBLEM TO PROJECT
PLANNING BECAUSE OF THE UNCERTAIN NUMBER OF CYCLES REQUIRED
TO CONSTRUCT THE PRODUCT.
• SECOND, EVOLUTIONARY SOFTWARE PROCESSES DO NOT ESTABLISH THE
MAXIMUM SPEED OF THE EVOLUTION. IF THE EVOLUTIONS OCCUR TOO
FAST, WITHOUT A PERIOD OF RELAXATION, IT IS CERTAIN THAT THE PROCESS
WILL FALL INTO CHAOS. ON THE OTHER HAND IF THE SPEED IS TOO SLOW
THEN PRODUC TIVITY COULD BE AFFECTED .
• THIRD, SOFTWARE PROCESSES SHOULD BE FOCUSED ON FLEXIBILITY
AND EXTENSIBILITY RATHER THAN ON HIGH QUALITY.. HOWEVER, WE
SHOULD PRIORITIZE THE SPEED OF THE DEVELOPMENT OVER ZERO
DEFECTS. EXTENDING THE DEVELOPMENT IN ORDER TO REACH HIGH
QUALITY COULD RESULT IN A LATE DELIVERY OF THE PRODUCT, WHEN THE
OPPORTUNITY NICHE HAS DISAPPEARED.
 SPECIALIZED PROCESS MODELS
• 1.COMPONENT-BASED DEVELOPMENT
• COMMERCIAL OFF-THE-SHELF (COTS) SOFTWARE
COMPONENTS, DEVELOPED BY VENDORS WHO OFFER THEM
AS PRODUCTS,
• PROVIDE TARGETED FUNCTIONALITY WITH WELL-DEFINED
INTERFACES THAT ENABLE THE COMPONENT TO BE
INTEGRATED INTO THE SOFTWARE THAT IS TO BE BUILT.
• THE COMPONENT-BASED DEVELOPMENT MODEL
INCORPORATES MANY OF THE CHARACTERISTICS OF THE
SPIRAL MODEL. IT IS EVOLUTIONARY IN NATURE
• DEMANDING AN ITERATIVE APPROACH TO THE CREATION
OF SOFTWARE.
• THE COMPONENT-BASED DEVELOPMENT MODEL INCORPORATES
THE FOLLOWING STEPS
• 1. AVAILABLE COMPONENT-BASED PRODUCTS ARE RESEARCHED
AND EVALUATED FOR THE APPLICATION DOMAIN IN QUESTION.
• 2. COMPONENT INTEGRATION ISSUES ARE CONSIDERED.
• 3. A SOFTWARE ARCHITECTURE IS DESIGNED TO
ACCOMMODATE THE COMPONENTS.
• 4. COMPONENTS ARE INTEGRATED INTO THE ARCHITECTURE.
• 5. COMPREHENSIVE TESTING IS CONDUCTED TO ENSURE
PROPER FUNCTIONALITY
• THE COMPONENT-BASED DEVELOPMENT MODEL INCORPORATES
THE FOLLOWING STEPS
• 1. AVAILABLE COMPONENT-BASED PRODUCTS ARE
RESEARCHED AND EVALUATED FOR THE APPLICATION
DOMAIN IN QUESTION.
• 2. COMPONENT INTEGRATION ISSUES ARE CONSIDERED.
• 3. A SOFTWARE ARCHITECTURE IS DESIGNED TO
ACCOMMODATE THE COMPONENTS.
• 4. COMPONENTS ARE INTEGRATED INTO THE ARCHITECTURE.
• 5. COMPREHENSIVE TESTING IS CONDUCTED TO ENSURE
PROPER FUNCTIONALITY
• 2.THE FORMAL METHODS MODEL
• THE FORMAL METHODS MODEL ENCOMPASSES A SET OF
ACTIVITIES THAT LEADS TO FORMAL MATHEMATICAL
SPECIFICATION OF COMPUTER SOFTWARE
• A VARIATION ON THIS APPROACH, CALLED CLEANROOM
SOFTWARE ENGINEERING
• AMBIGUITY, INCOMPLETENESS, AND INCONSIS TENCY CAN BE
DISCOVERED AND CORRECTED MORE EASILY—NOT THROUGH
AD HOC REVIEW, BUT THROUGH THE APPLICATION OF
MATHEMATICAL ANALYSIS.
• ISSUES WITH FORMAL METHOD:
• THE DEVELOPMENT OF FORMAL MODELS IS CURRENTLY QUITE
TIME CONSUMING AND EXPENSIVE.
• • BECAUSE FEW SOFTWARE DEVELOPERS HAVE THE
NECESSARY BACKGROUND TO APPLY FORMAL METHODS,
EXTENSIVE TRAINING IS REQUIRED.
• • IT IS DIFFICULT TO USE THE MODELS AS A
COMMUNICATION MECHANISM FOR TECHNICALLY
UNSOPHISTICATED CUSTOMERS.
• 3.ASPECT-ORIENTED SOFTWARE DEVELOPMENT
• AS MODERN COMPUTER-BASED SYSTEMS BECOME MORE
SOPHISTICATED (AND COMPLEX), CERTAIN CONCERNS SPAN THE
ENTIRE ARCHITECTURE.
• SOME CONCERNS ARE HIGH-LEVEL PROPERTIES OF A SYSTEM (E.G.,
SECURITY, FAULT TOLERANCE).
• OTHER CONCERNS AFFECT FUNCTIONS (E.G., THE APPLICATION OF
BUSINESS RULES),
• WHILE OTHERS ARE SYSTEMIC (E.G., TASK SYNCHRONIZATION OR
MEMORY MANAGEMENT).
• WHEN CONCERNS CUT ACROSS MULTIPLE SYSTEM FUNCTIONS,
FEATURES, AND INFORMATION, THEY ARE OFTEN REFERRED TO AS
CROSSCUTTING CONCERNS.
• ASPECTUAL REQUIREMENTS DEFINE THOSE CROSSCUTTING
CONCERNS THAT HAVE AN IMPACT ACROSS THE SOFTWARE
ARCHITECTURE.
• ASPECT-ORIENTED SOFTWARE DEVELOPMENT (AOSD), OFTEN
REFERRED TO AS ASPECT-ORIENTED PROGRAMMING(AOP), IS A
RELATIVELY NEW SOFTWARE ENGINEERING PARADIGM
• THAT PROVIDES A PROCESS AND METHODOLOGICAL APPROACH FOR
• DEFINING,
• SPECIFYING,
• DESIGNING,
• AND CONSTRUCTING ASPECTS—“MECHANISMS BEYOND
SUBROUTINES AND INHERITANCE FOR LOCALIZING THE EXPRESSION
OF A CROSSCUTTING CONCERN”
 THE UNIFIED PROCESS
• THE UNIFIED PROCESS IS AN ATTEMPT TO DRAW ON THE BEST
FEATURES AND CHARACTERISTICS OF TRADITIONAL SOFTWARE
PROCESS MODELS, BUT CHARACTERIZE THEM IN A WAY THAT IMPLEMENTS
MANY OF THE BEST PRINCIPLES OF AGILE SOFTWARE DEVELOPMENT
• THE UNIFIED PROCESS RECOGNIZES THE IMPORTANCE OF CUSTOMER
COMMUNICATION AND STREAMLINED METHODS FOR DESCRIBING
THE CUSTOMER’S VIEW OF A SYSTEM (THE USE CASE).
• IT EMPHASIZES THE IMPORTANT ROLE OF SOFTWARE ARCHITECTURE AND
“HELPS THE ARCHITECT FOCUS ON THE RIGHT GOALS, SUCH AS
UNDERSTANDABILITY, RELIANCE TO FUTURE CHANGES, AND REUSE”
• . IT SUGGESTS A PROCESS FLOW THAT IS ITERATIVE AND
INCREMENTAL, PROVIDING THE EVOLUTIONARY FEEL THAT IS
ESSENTIAL IN MODERN SOFTWARE DEVELOPMENT.
 THE UNIFIED PROCESS
• PHASES OF THE UNIFIED PROCESS
 THE UNIFIED PROCESS
• THE INCEPTION PHASE OF THE UP ENCOMPASSES BOTH CUSTOMER
COMMUNICATION AND PLANNING ACTIVITIES.
BY COLLABORATING WITH STAKEHOLDERS, BUSINESS REQUIREMENTS
FOR THE SOFTWARE ARE IDENTIFIED; A ROUGH ARCHITECTURE FOR
THE SYSTEM IS PROPOSED; AND A PLAN FOR THE ITERATIVE,
INCREMENTAL NATURE OF THE ENSUING PROJECT IS DEVELOPED
FUNDAMENTAL BUSINESS REQUIREMENTS ARE DESCRIBED THROUGH A
SET OF PRELIMINARY USE CASES THAT DESCRIBE WHICH FEATURES AND
FUNCTIONS EACH MAJOR CLASS OF USERS DESIRES
• THE ELABORATION PHASE ENCOMPASSES THE COMMUNICATION AND
MODELING ACTIVITIES OF THE GENERIC PROCESS MODEL
ELABORATION REFINES AND EXPANDS THE PRELIMINARY USE CASES THAT
WERE DEVELOPED AS PART OF THE INCEPTION PHASE AND EXPANDS THE
ARCHITECTURAL REPRESENTATION TO INCLUDE FIVE DIFFERENT VIEWS
OF THE SOFTWARE—THE USE CASE MODEL, THE REQUIREMENTS MODEL,
THE DESIGN MODEL, THE IMPLEMENTATION MODEL, AND THE
 THE UNIFIED PROCESS
• THE CONSTRUCTION PHASE OF THE UP IS IDENTICAL TO THE
CONSTRUCTION ACTIVITY DEFINED FOR THE GENERIC SOFTWARE PROCESS.
 USING THE ARCHITECTURAL MODEL AS INPUT, THE CONSTRUCTION
PHASE DEVELOPS OR ACQUIRES THE SOFTWARE COMPONENTS THAT
WILL MAKE EACH USE CASE OPERATIONAL FOR END USERS.
AS COMPONENTS ARE BEING IMPLEMENTED, UNIT TESTS ARE DESIGNED
AND EXECUTED FOR EACH. IN ADDITION, INTEGRATION ACTIVITIES
(COMPONENT ASSEMBLY AND INTE GRATION TESTING) ARE CONDUCTED.
• THE TRANSITION PHASE OF THE UP ENCOMPASSES THE LATTER STAGES
OF THE GENERIC CON STRUCTION ACTIVITY AND THE FIRST PART OF THE
GENERIC DEPLOYMENT (DELIVERY AND FEEDBACK) ACTIVITY.
SOFTWARE IS GIVEN TO END USERS FOR BETA TESTING AND USER
FEEDBACK REPORTS BOTH DEFECTS AND NECESSARY CHANGES. IN
ADDITION, THE SOFTWARE TEAM CREATES THE NEC ESSARY SUPPORT
INFORMATION (E.G., USER MANUALS, TROUBLESHOOTING GUIDES,
INSTALLATION PROCEDURES) THAT IS REQUIRED FOR THE RELEASE.
 THE UNIFIED PROCESS
• THE PRODUCTION PHASE OF THE UP COINCIDES WITH THE DEPLOYMENT
ACTIVITY OF THE GENERIC PROCESS. DURING THIS PHASE, THE ONGOING
USE OF THE SOFTWARE IS MONITORED, SUPPORT FOR THE
OPERATING ENVIRONMENT (INFRASTRUCTURE) IS PROVIDED, AND
DEFECT REPORTS AND REQUESTS FOR CHANGES ARE SUBMITTED
AND EVALUATED.
 PERSONAL AND TEAM PROCESS MODELS
• PERSONAL SOFTWARE PROCESS (PSP) :THE PSP MODEL DEFINES FIVE
FRAMEWORK ACTIVITIES:
• PLANNING.
THIS ACTIVITY ISOLATES REQUIREMENTS AND DEVELOPS BOTH SIZE AND
RESOURCE ESTIMATES.
 IN ADDITION, A DEFECT ESTIMATE (THE NUMBER OF DEFECTS
PROJECTED FOR THE WORK) IS MADE.
ALL METRICS ARE RECORDED ON WORKSHEETS OR TEMPLATES.
 FINALLY, DEVELOPMENT TASKS ARE IDENTIFIED AND A PROJECT
SCHEDULE IS CREATED.
• HIGH-LEVEL DESIGN.
EXTERNAL SPECIFICATIONS FOR EACH COMPONENT TO BE CON
STRUCTED ARE DEVELOPED AND A COMPONENT DESIGN IS CREATED.
PROTOTYPES ARE BUILT WHEN UNCERTAINTY EXISTS. ALL ISSUES ARE
RECORDED AND TRACKED.
 PERSONAL AND TEAM PROCESS MODELS
• HIGH-LEVEL DESIGN REVIEW.
 FORMAL VERIFICATION METHODS ARE APPLIED TO UNCOVER ERRORS
IN THE DESIGN.
 METRICS ARE MAINTAINED FOR ALL IMPORTANT TASKS AND WORK
RESULTS.

• DEVELOPMENT.
• THE COMPONENT-LEVEL DESIGN IS REFINED AND REVIEWED.
• CODE IS GENERATED, REVIEWED, COMPILED, AND TESTED. METRICS ARE
MAINTAINED FOR ALL IMPORTANT TASKS AND WORK RESULTS.

• POSTMORTEM.
 USING THE MEASURES AND METRICS COLLECTED (THIS IS A SUBSTAN TIAL
AMOUNT OF DATA THAT SHOULD BE ANALYZED STATISTICALLY), THE
EFFECTIVENESS OF THE PROCESS IS DETERMINED.
MEASURES AND METRICS SHOULD PROVIDE GUIDANCE FOR MODIFYING THE
 TEAM PROCESS MODELS
THE GOAL OF TSP IS TO BUILD A “SELF DIRECTED” PROJECT TEAM THAT
ORGANIZES ITSELF TO PRODUCE HIGH-QUALITY SOFTWARE. HUMPHREY
[HUM98] DEFINES THE FOLLOWING OBJECTIVES FOR TSP
• BUILD SELF-DIRECTED TEAMS THAT PLAN AND TRACK THEIR WORK,
ESTABLISH GOALS, AND OWN THEIR PROCESSES AND PLANS. THESE
CAN BE PURE SOFTWARE TEAMS OR INTEGRATED PRODUCT TEAMS (IPTS) OF
3 TO ABOUT 20 ENGINEERS.
• SHOW MANAGERS HOW TO COACH AND MOTIVATE THEIR TEAMS AND HOW
TO HELP THEM SUSTAIN PEAK PERFORMANCE.
• ACCELERATE SOFTWARE PROCESS IMPROVEMENT BY MAKING CMM LEVEL
5 BEHAVIOR NORMAL AND EXPECTED.
• PROVIDE IMPROVEMENT GUIDANCE TO HIGH-MATURITY ORGANIZATIONS.
• FACILITATE UNIVERSITY TEACHING OF INDUSTRIAL-GRADE TEAM SKILLS.