4351

describes best practices for managing and developing the workforce of an organization.  P-CMM is a framework for improving an organization’s processes for managing and developing its workforce, and no specific approach to team organization is put forward.

–degree of communication (LOW to HIGH COUPLING)

–ability of individuals to communicate their ideas (LOW to HIGH COHESION)

Software failures can result from breakdown in communication and understanding

• –clearly decide who should be in the meeting
• –develop an agenda
• –have someone who tracks the discussion
• –have someone who ensures follow-up actions

–Successful manager and highly skilled  programmer

• –Does the Architectural Design (OOA)
• –Allocates coding among the Team Members

–The Backup Programmer must be in every way as competent as the Chief Programmer, and

–Must know as much about the project as the Chief Programmer

–The Backup Programmer does Black Box Test Case planning and other tasks that are independent of the Design process

• –Responsible for maintaining the program production library (documentation of the project), including:
• »Source code listings
• »JCL
• »Test data

The Chief Programmer must be a highly skilled Programmer and a successful Manager

There is a shortage of highly skilled Programmers

There is a shortage of successful Managers

The qualities needed to be a highly skilled Programmer are unlikely to be found in a successful Manager, and vice versa

The Team Leader is responsible for only technical Management

Team Manager only does non technical management of the team.

Works well for large projects, Project leader over Team Leaders who oversee small parallel teams.

• 3/4 BUILDS per project
• At the end of the day — synchronize (test and debug)
• At the end of the build — stabilize (freeze the build)

Pair programming, programmers do not test their own code

• staffing,      
• communication and coordination,        
• training and development,        
• work environment,        
• performance management,        
• coordination

• A rigid discipline is maintained in specifying the product’s deisgn
• B the chief programmer takes personal responsibility for each line of code
• C non-technical managerial decisions are handled within the group
• D communication and coordination are handled by the programming secretary
• **E individual creativity and autonomy are nutured

• A programmers do not test their own code
• **B there is still too little evidence regarding its efficacy
• C less experienced programmers can learn from others
• D group ownership of code
• E none of these, they are all strengh

• 1. regression
• 2. synchronization
• 3. stabilization
• **4. refactoring
• 5. incrementing

• 1. build-and-fix
• 2. rapid prototyping
• 3. synchronize and stabilize
• 4. fountain
• **5. all are software life-cycle models

• 1. upperCASE tool
• 2. lowerCASE tool
• 3. compiler
• 4. structure editor
• **5. configuration management tool

**5. postpone decisions on details until as late as possible in order to be able to concentrate on the important issues

–The Software Engineer can concentrate on the relevant aspects

**5. the extent to which the product satisfies its specification

Regression Testing

• 1. data
• 2. procedural
• 3. iteration
• **4. all of these
• 5. none of these

• 1. In an object-orientated design the system state is decentralised and each object manages its own state information. 
• 2. In functional design the system state is centralised and state information is accessed by different functions.

3. Functional and object-orientated approaches are complementary techniques.

4. the most appropriate design strategy is selected for each stage of design, there is no need to adhere to a single approach during the whole design process.

** 5. The same design approach must be used in the design of different system components to ensure consistency, especially for large software systems.

** 1. the fragile base class problem

** 4. to reduce its complexity and functional duplication.

Any change to a software product can potentially cause a regression fault

ALL 5 flows are worked on during the entire lifecycle!!

• REQUIREMENTS WORKFLOW
• ANALYSIS WORKFLOW
• DESIGN WORKFLOW
• IMPLEMENTATION WORKFLOW
• TESTING WORKFLOW

each increment is viewed as a miniature and complete waterfall

• INCEPTION
• ELABORATION
• CONSTRUCTION
• TRANSITION

–Rapid prototyping model plus risk analysis preceding each phase

• Precede each phase by
• –Alternatives
• –Risk analysisl

• Follow each phase by
• –Evaluation
• –Planning of the next phase

• Strengths
• –It is easy to judge how much to test
• –No distinction is made between development and maintenancel

• Weaknesses
• –For large-scale software only
• –For internal (in-house) software only

easiest but most costly way to develop software

no specifications, no design

• –Analytical (theoretical) tools
• »Stepwise Refinement
• »Cost Benefit Analysis
• »Software Metrics

• –Software tools
• »products that  assist with software development and maintaining software
• »CASE tools

• Size
• –In Lines Of Code

• Cost
• –In Dollars

• Duration
• –In Months

• Effort
• –In Person-Months

• Quality
• –Number of Faults detected

can support the entire software lifecycle.

UpperCASE (front end tool)

LowerCASE (back end tool)

Online Interface Checkers (intellisense)

• Source Level Debugger to:
• –Machine-code core dumps 
• –Assembler listings
• –Linker listings
• –Similar low-level documentation

(Subversion control)

• SVN
• SOURCESAFE

CASE Environments should be used at CMM level 3 or higher

• RED PHASE:
• Buisness modeling (Feasability study, line numbers doc w/ use case)
• Analysis & Design (line numbers doc w/ classes)

• Purple Phase:
• Requirements (SRS software requirements specification)
• Implementation (Website design)

walkthroughs detect faults, not correct them.

• –Two-step, informal process
• »Preparation
• »Analysis

faults recorded by severity and fault type

• –Five-step, formal process
• »Overview
• »Preparation
• »Inspection
• »Rework
• »Follow-up

–“The Process of inferring certain behavioral properties of the product based, in part, on the results of executing the product in a known environment with selected inputs”

A product is Correct if it satisfies its Specifications

The extent to which the product meets the user’s needs

A measure of the frequency and criticality of failure

• A function of
• –The range of operating conditions
• –The possibility of unacceptable results with valid input
• –The effect of invalid input

The extent to which space and time constraints are met

Software engineers do not have enough mathematics for proofs

Proving is too expensive to be practical

Proving is too hard

• –The programmer does informal Testing (TDD, Unit Testing)
• –The SQA group then does systematic Testing

Structure diagrams model the structure of the system (the static model)

Behavior diagrams model the dynamic behavior of the system (the dynamic model)

system modelling helps the analyst to understand the functionality of the system and models are used to communicate with customers.

• Data processing model showing how the data is processed at different stages.
• Composition model showing how entities are composed of other entities.
• Architectural model showing principal subsystems.
• Classification model showing how entities have common characteristics.
• Stimulus/response model showing the system ’s reaction to events.
• Context models are used to illustrate the operational context of a system - they show what lies outside the system boundaries.

lData dictionaries are lists of all of the names used in the system models. Descriptions of the Entities, Relationships and Attributes are also included.

Module cohesion–Degree of interaction within a module

Module coupling–Degree of interaction between modules

• 1-A module has coincidental [BAD] cohesion if it performs multiple, completely unrelated actions
• The problem is easy to fix–Break the module into separate modules, each performing one task

• 2-A module has logical cohesion when it performs a series of related actions, one of which is selected by the calling module
• Difficult to reuse

• 3-A module has temporal cohesion when it performs a series of actions related in time
• The actions of this module are weakly related to one another, but strongly related to actions in other modules

4-A module has procedural cohesion if it performs a series of actions related by the procedure to be followed by the product

5-A module has communicational cohesion if it performs a series of actions related by the procedure to be followed by the product, but in addition all the actions operate on the same data

• 6-A module with functional cohesion performs exactly one action
• more reusable and extendable

7-A module has informational cohesion if it performs a number of actions, each with its own entry point, with independent code for each action, all performed on the same data structure

• 1-Two modules are content coupled if one directly references contents of the other
• BAD-It is impossible to reuse module p without reusing module q

• 2-Two modules are common coupled if they have write access to global data
• bad–The resulting code is virtually unreadable

• 3-Two modules are control coupled if one passes  an element of control to the other, i.e., one module explicitly controls the logic of the other.
• bad-The modules are not independent

• 4-Two modules are stamp coupled if a data structure is passed as a parameter, but the called module operates on some but not all of the individual components of the data structure
• bad-It is not clear, without reading the entire module, which fields of a record are accessed or changed

• 5-Two modules are data coupled if all parameters are homogeneous data items (simple parameters, or data structures all of whose elements are used by called module)
• good-The difficulties of content, common, control, and stamp coupling are not present

Data encapsulation is an example of abstraction

Advantages

• –Development
• – conceptual independence
• –Gather into unit all aspects of the real
• -world entity modeled by that unit.

• –Maintenance
• – identify aspects of a product likely to change
• –Design the product to minimize the effects of future changes.

• –Conceptualize problem at a higher level
• »Job queues and operations on job queues

• –Not a lower level
• »Records or arrays

• 1.  Design the product in terms of higher level concepts
• –It is irrelevant how job queues are implemented

• 2.  Then design the lower level components
• –Totally ignore what use will be made of them

• –Design the modules in a way that items likely to change are hidden
• –Future change is localized
• –Changes cannot affect other modules

• 2 kinds:
• Data abstraction
• Procedural abstraction

Aggregation-Refers to the components of a class

Association-Relationship of some kind between two classes

• –Can have a negative impact on maintenance
• »The code is hard to understand if there are multiple possibilities for a specific method

–A strength and a weakness of the Object Oriented Paradigm