Post on 29-Dec-2015
2
Software Engineering
A Layered A Layered TechnologyTechnology
Software Engineering
a “quality” focusa “quality” focus
process modelprocess model
methodsmethods
toolstools
3
A Common Process A Common Process FrameworkFramework
Common process frameworkCommon process framework
Framework activitiesFramework activities
work taskswork tasks
work productswork products
milestones & deliverablesmilestones & deliverables
QA checkpointsQA checkpoints
Umbrella ActivitiesUmbrella Activities
4
Umbrella Umbrella ActivitiesActivities
Software project managementSoftware project management Formal technical reviewsFormal technical reviews Software quality assuranceSoftware quality assurance Software configuration managementSoftware configuration management Document preparation and Document preparation and
productionproduction Reusability managementReusability management MeasurementMeasurement Risk managementRisk management
5
The Process The Process Model:Model:
AdaptabilityAdaptability the framework activities will the framework activities will alwaysalways be be applied on applied on everyevery project ... BUT project ... BUT
the tasks (and degree of rigor) for each the tasks (and degree of rigor) for each activity will vary based on:activity will vary based on:
the type of project (an “entry point” to the model)the type of project (an “entry point” to the model)characteristics of the projectcharacteristics of the projectcommon sense judgment; concurrence of the project common sense judgment; concurrence of the project
teamteam
7
Waterfall ModelSSR - System Software Review
PDR - Preliminary Design Review
CDR - Critical Design Review
TRR - Test Rediness Review
FCA - Functional Configuration Audit
PCA - Physical Configuration Audit
ORR - Operational Rediness ReviewSoftwareRequirements
AnalysisSoftwareDesign
Code and UnitTesting
SoftwareIntegrationand Test
SoftwareAcceptance
Test
SSR PDR CDR TRR CRRFCAPCA
SRS
SDS
STP
SIP
8
SoftwareRequirements
Analysis
DetailedSoftwareDesign
Code and UnitTesting
SoftwareIntegration
and Test SoftwareAcceptance
Test
SSR PDR CDR TRR FCAPCA
SystemDesign
PreliminarySoftwareDesign
SDR
HardwareHardware
Implementation
Operational Timelines
Waterfall - DOD Model NASA Model)
SRS
PP
PDD
SDS
STPSIP
9
Rapid Application Development ModelRapid Throwaway Prototype Model
SoftwareRequirements
Analysis
SoftwareDesign
Code and UnitTesting Software
Integrationand Test Software
AcceptanceTest
SSR PDR CDR TRR CRRFCAPCA
BuildPrototype
PR
SRS
PDD
SDS
STP
SIP
10
RAD RAD CharacteristicsCharacteristics High speed adaptation of the linear model
Based on Component-based construction Has incremental flavor Not well- suited where precision is required,
e.g. high risk systems not easily modularized systems
Have rigid performance requirements1. Model the Information Flow2. Refine the flows into Data elements3. Model the data transformations4. Generate the code 4GLs, component reuse, CASE5. Test and integration
11
Reuse and Automated Development Models/Component Assembly Model
SoftwareRequirements
AnalysisSoftwareDesign
Code and UnitTesting Software
Integrationand Test Software
AcceptanceTest
SSR PDR CDR TRR CRRFCAPCA
Identify Reusable Components
Informal Specification Formal Specifications Code
SRS
SDS
STP
SIP
12
Component Based Component Based DevelopmentDevelopment
Architecture for Software ReuseBased on Object OrientationClasses are stored in a libraryWhen requirements are received,the first
stop is the library
13
Linear Model Linear Model CharacteristicsCharacteristics
Documentation driven model
systematic and requires rigor.
Inflexible partitioning of project into distinct stages
difficult to respond to changes in customer requirements
Model appropriate when requirements are well-understood.
Programmers HATE to create documentation.
Users HATE to read documentation.
If users read, they rarely understand documentation.
Programmers don't understand other programmers documentations.
Standards for documentation not clear although UML ordained.
14
Iterative Iterative ModelsModels
listento
customerbuild/revisemock-up
customertest-drivesmock-up
Prototyping
15
Evolutionary (Prototype) Model
ONLY A PART OF THE FULL SYSTEM
Series of Implementations of each PART
SoftwareRequirements
Analysis
SoftwareDesign
Code and UnitTesting Software
Integrationand Test Software
AcceptanceTest
SSR PDR CDR TRR CRRFCAPCA
BuildPrototype
PR
SRS
PDD
SDS
STP
SIP
16
Evolutionary/Prototype Evolutionary/Prototype ModelModel
IssuesIssuesProcess is not visibleProcess is not visible--Lack of process visibility--Lack of process visibilitySystems are often poorly structuredSystems are often poorly structured—Change —Change
tends to corrupt the structurestends to corrupt the structuresSpecial tools and techniques may be requiredSpecial tools and techniques may be required——
Special skills (e.g. in languages for rapid Special skills (e.g. in languages for rapid prototyping) may be requiredprototyping) may be required
ApplicabilityApplicabilityFor small or medium-size interactive systemsFor small or medium-size interactive systemsFor parts of large systems (e.g. the user For parts of large systems (e.g. the user
interface)interface)For short-lifetime systemsFor short-lifetime systems
17
Iterative Iterative ModelsModels
businessmodeling
datamodeling
processmodeling
applicationgeneration
testing&
turnover
b u s i n e s sm o d e l i n g
d a t am o d e l i n g
p r o c e s sm o d e l i n g
a p p l i c a t i o ng e n e r a t i o n
t e s t in g&
t u r n o v e r
b u s i n e s sm o d e l i n g
d a t am o d e l i n g
p r o c e s sm o d e l i n g
a p p l i c a t i o ng e n e r a t i o n
t e s t i n g&
t u r n o v e r
team #1team #2
team #3
60 - 90 days
RAD
18
The Incremental The Incremental ModelModel
analysis design code test
System/informationengineering
analysis design code test
analysis design code test
analysis design code test
increment 2
increment 3
increment 4
increment 1
delivery of1st increment
delivery of2nd increment
delivery of3rd increment
delivery of4th increment
calendar time
19
SoftwareRequirements
AnalysisSoftwareDesign
Code and UnitTesting Software
Integrationand Test Software
AcceptanceTest
SSR PDR CDR TRR CRRFCAPCA
Incremental Development Model
ONLY A PART OF THE FULL SYSTEM
Can Determine a PART at any phase.
SRS
SDS
STP
SIP
20
Characteristics of Incremental Characteristics of Incremental ModelModel
Same Requirements, specification, maintenance,and requirement phases as in Waterfall
The systems is partitioned into builds where each build is independently designed and scheduled "incrementally“ The 1st build gives some "production"functionality Subsequent builds add functionality
User perspective Get some results quickly Reduces new system "culture shock"
21
Characteristics of Incremental Characteristics of Incremental ModelModel
Costs easily prorated over the development cycle It employs the systems approach Changes are easier to implement (e.g.design of later
builds may not start until some phases are complete and all their changes well known).
Problems - May degenerate into "Build and Fix“ May result in builds that cannot integrate with one
another
22
Spiral Model
Risk Analysis
Prototyping
Planning
Client Evaluation and Input
Simulation
Operational Prototype
Verification for Next Level
Developing
23
An Evolutionary (Spiral) An Evolutionary (Spiral) ModelModel
CustomerCommunication
Planning
Construction & ReleaseCustomerEvaluation
Engineering
Risk Analysis
Prototyping
Simulation/ Operational Prototype/Verification for the Next Level/Development
And input
24
CleanRoom Approach
SpecificationIncremental Development
Planning Specificationand Design
StatisticalTesting
Certification
UsageDesign
25
REQUIREMENTSANALYSIS
SYSTEMDESIGN
PROGRAMDESIGN
CODING
UNIT & INTE-GRATION TESTING
SYSTEMTESTING
ACCEPTANCETESTING
OPERATION& MAINTENANCE
Verify design
Validate requirements
[Pfleeger 98]
V V ModelModel
26
Operational Specification Operational Specification ModelModel
DELIVEREDSYSTEM
Execute andRevise
SYSTEMREQUIREMENTS
(sometimes informalor incomplete)
TESTOPERATIONALSPECIFICATION
(problem-oriented)
TRANSFORMEDSPECIFICATION
(implementation-oriented)
[Pfleeger 98]
27
Still Other Process Still Other Process ModelsModels
Concurrent process modelConcurrent process model——recognizes that different part of recognizes that different part of the project will be at different the project will be at different places in the processplaces in the process
Formal methodsFormal methods—the process to —the process to apply when a mathematical apply when a mathematical specification is to be developedspecification is to be developed
28
Formal Method Formal Method CharacteristicsCharacteristics
Formal Methods Model Specifications produce proofsRequired rigorous notationEnhances accuracyReduces flexibility
Some Formal Methods Petri Nets, Zed, Hoare Logic, CSP, Weakest Preconditions
Formal Methods AbstractionAdd formality to reduce ambiguity Use graphical representations
Describe the possible system states, transitions, and triggers
29
Capability Maturity Capability Maturity ModelModel
Organizations are not born using a mature Organizations are not born using a mature process model. process model.
Most organizations use NO known process Most organizations use NO known process modelmodel
Watts Humphrey wrote a book to lay out a plan Watts Humphrey wrote a book to lay out a plan for improving the process model within for improving the process model within organizations. His book “Managing the organizations. His book “Managing the Software Process” and other research has Software Process” and other research has greatly improved the software engineering greatly improved the software engineering process. process.
The SEI Developed a capability maturity model The SEI Developed a capability maturity model which proposes a model for maturing an which proposes a model for maturing an organizations process model. organizations process model.
30
Capability Maturity Capability Maturity ModelModel
Five Process Maturity LevelsFive Process Maturity LevelsLevel 0: ChaosLevel 0: ChaosLevel 1: InitialLevel 1: InitialLevel 2: RepeatableLevel 2: RepeatableLevel 3: DefinedLevel 3: DefinedLevel 4: ManagedLevel 4: ManagedLevel 5: OptimizingLevel 5: Optimizing
31
Level 1: Level 1: InitialInitial
The software process is The software process is characterized as ad hoc, characterized as ad hoc, and occasionally even and occasionally even chaotic. Few processes chaotic. Few processes are defined, and are defined, and success depends on success depends on individual effort.individual effort.
32
Level 2: Level 2: RepeatableRepeatable
Basic project management Basic project management processes are established to processes are established to track cost, schedule, and track cost, schedule, and functionality. The necessary functionality. The necessary process discipline is in place process discipline is in place to repeat earlier successes to repeat earlier successes on projects with similar on projects with similar applicationsapplications
33
Process Maturing to Process Maturing to Level 2Level 2
Software configuration Software configuration managementmanagement
Software quality assuranceSoftware quality assurance Software subcontract Software subcontract
managementmanagement Software project tracking and Software project tracking and
oversightoversight Software project planningSoftware project planning Requirement managementRequirement management
34
Level 3: Level 3: DefinedDefined
The software process for both The software process for both management and engineering management and engineering activities is documented, activities is documented, standardized, and integrated into an standardized, and integrated into an organization-wide software process. organization-wide software process. All projects use a documented and All projects use a documented and approved version of the approved version of the organization’s process for developing organization’s process for developing and maintaining software. and maintaining software.
This level includes all characteristics This level includes all characteristics defined for level 2.defined for level 2.
35
Process Maturing Process Maturing Level 3Level 3
Peer ReviewsPeer Reviews Inter-group coordinationInter-group coordination Software product engineeringSoftware product engineering Integrated software managementIntegrated software management Training programTraining program Organization process definitionOrganization process definition Organization process focusOrganization process focus
36
Level 4: Level 4: ManagedManaged
Detailed measures of the Detailed measures of the software process and product software process and product quality are collected. Both the quality are collected. Both the software process and products software process and products are quantitatively understood are quantitatively understood and controlled using detailed and controlled using detailed measures.measures.
This level includes all This level includes all characteristics defined for level 3.characteristics defined for level 3.
37
Process Maturing Process Maturing Level 4Level 4
Software quality Software quality managementmanagement
Quantitative process Quantitative process managementmanagement
38
Level 5: Level 5: OptimizingOptimizing
Continuous process Continuous process improvement is enables by improvement is enables by quantitative feedback from the quantitative feedback from the process and from testing process and from testing innovative ideas and innovative ideas and technologiestechnologies
This level includes all This level includes all characteristics defined for level characteristics defined for level 5.5.
39
Process Maturing Process Maturing Level 5Level 5
Process change Process change managementmanagement
Technology change Technology change managementmanagement
Defect preventionDefect prevention
40
CMM CMM IssuesIssues
focuses on project management rather focuses on project management rather than than product development. product development.
ignores the use of technologies such as ignores the use of technologies such as rapid rapid prototyping.prototyping.
does not incorporate risk analysis as a key does not incorporate risk analysis as a key process areaprocess area
does not define its domain of applicabilitydoes not define its domain of applicability