1. Chapter 2 The Process

2. A Layered Technology Software Engineering Software Engineering tools
methods
process model
a “quality” focus
Software engineering has to do with process models which determine the SDLC used, methods or techniques for accomplishing the tasks outlined in the process model, CASE tools which are used to aid in software development and a quality focus to assure that the products are built with quality

3. A Common Process Framework
Framework activities
work tasks
work products
milestones & deliverables
QA checkpoints
Umbrella Activities
The software development process includes process activities and lower level tasks. An example of an activity might be to analysis data for potential databases. Some lower level tasks would be to define the data needed, construct the conceptual entity relationship diagram, attach attributes to the ERD, put the diagram in first normal form, place the diagram in second normal form, place the diagram in third normal form, determine if data needs to by in Boyce Codd normal form, place data in Boyce Codd normal form, if necessary, put the ERD in ER Win CASE tool, run CASE diagnostics, and resolve inconsistancies. Some milestones might be to obtain approval from a steering committee, obtain funding for development, install hardware for testing. Deliverables might include the ERD, case diagrams, requirements specification document, etc. QA checkpoints would include items such as a review of the requirements documents, review of code, etc. Umbrella activities would include development and maintenance of a project plan, updating estimates, updating risk assessment, etc.

4. Umbrella Activities Software project management
Formal technical reviews
Software quality assurance
Software configuration management
Document preparation and production
Reusability management
Measurement
Risk management
Project management has to do with scheduling the tasks needed to be done for a software engineering project.
Formal technical reviews involve the review of deliverables including software products
Software quality assurance has to do with the tools and techniques for assuring the quality of a product including technical reviews.
Software configuration management has to do with the configuration of software. Suppose you have a piece of software on a satellite and you need to revise one piece of that software. You will need to know what compiler version is needed to compile that specific piece of software, what version of the operating system is needed, what version of the database management system is needed, which version of the communication software is needed, which version of the file management system is needed, and any other software supporting this one piece you need to change.
Reusability management allows programmers to reuse software components, entities, classes, use cases, elements, structures, etc.
Measurement means keeping metrics on the software product such as mean time between failure, number of failures, types of failures, and keeping metrics on the software process such as how well we do programming and how much time it takes to do that particular part of the software development process.
Risk management involves measuring the risks of a project such as the operatability risk, development risks, schedule risks, and maintenance risks.

5. The Process Model: Adaptability
the framework activities will always be applied on every project ... BUT
the tasks (and degree of rigor) for each activity will vary based on:
the type of project (an “entry point” to the model)
characteristics of the project
common sense judgment; concurrence of the project team
Not ALL activities in the process model will be used on EVERY project
But the activities and task outline all known task that could be done.
Each project is different and may vary on the tasks,
I believe it was Larry Constatine who said that the process model was not a cookbook. I disagree, it is a cookbook, but you cannot just pick up a cookbook and cook. You will have to know how to cook to use a cookbook. If you do not know how to cream butter the cookbook will not help. The cookbook is just a receipt for success. Only good cooks can use it.

6. Linear Models
There are many linear models of software engineering in which you go through analysis, design, code and test.

7. Waterfall Model SRS SDS STP SIP SSR PDR CDR TRR FCA PCA CRR Software
SSR - 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 Review
Software
Requirements
Analysis
Software
Design
SRS
Code and Unit
Testing
SDS
Software
Integration
and Test
STP
Software
Acceptance
Test
SIP
The waterfall is such a model. A large project may sty in analysis for several years. Imagine how much the requirements may change during that time. Design may last several months for the same project. Coding, testing and implementation may take another several years.
SSR
PDR
CDR
TRR
FCA
PCA
CRR

8. Waterfall - DOD Model NASA Model)
Software
Requirements
Analysis
Detailed
Design
Code and Unit
Testing
Integration
and Test
Acceptance
Test
SSR
PDR
CDR
TRR
FCA
PCA
System
Preliminary
SDR
Hardware
Implementation
Operational
Timelines PP
SRS
PDD
SDS
STP
Note the NASA model is very similar to the WM. One big difference is in the LBR SD phase where the project proposal (PP) is created. This allows estimation of the needed software, hardware so the LBR can be written.
SIP

9. Rapid Application Development Model Rapid Throwaway Prototype Model
Software
Requirements
Analysis
Design
Code and Unit
Testing
Integration
and Test
Acceptance
Test
SSR
PDR
CDR
TRR
CRR
FCA
PCA
Build
Prototype PR
SRS
PDD
SDS
STP
RAD is a technique so that a prototype can be built.
Problem, often the design of the prototype follows the software
Problem, user thinks the entire system is complete or near completion while the database may not even be working
Design may not happen because of the design of the prototype not allowing debate over design decisions or design reviews.
Called quick and dirty (dirty design) for a reason.
SIP

10. RAD Characteristics 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 requirements
1. Model the Information Flow
2. Refine the flows into Data elements
3. Model the data transformations
4. Generate the code 4GLs, component reuse, CASE
5. Test and integration
It makes th WF model go faster
Allows building of some reusable components
NOT SUITED FOR software where PRCISION IS REQUIRED
precision for timing, money, calculations, etc

11. Reuse and Automated Development Models/Component Assembly Model
Software
Requirements
Analysis
Design
Code and Unit
Testing
Integration
and Test
Acceptance
Test
SSR
PDR
CDR
TRR
CRR
FCA
PCA
SRS
SDS
STP
SIP
This is no different than a short linear model BUT it has emphasis on REUSE.
Here is a GOOD SOFTWARE ENGINEERING RESEARCH PROJECT
Note there are reusable components after analysis – called analysis patterns
Example: Regardless of the system, if there are inputs and you plan to validate those inputs using a GUI. Hmm there are similar validations techniques such as range validation, discrete validation, alphabetic validation, numeric with length validation, numeric with limited length validation, numeric with 2 dashes, numeric with 2 decimal places, etc…….Do I really want to write all of those OR can I implement a reflective architecture to use these. I specifiy the metadata regarding validation such as the min and max, the code table for discrete values, the length limit for digits with length in a data dictionary. I have a interface or supertype called Validate and sub types which have isValid routines. I use reflection and polymorphism to validate the values. I reflect the needed validation class to validate the values and I polymorphicly call the isValid routine.
This is just one analysis pattern there are multiple patterns defined by Joe Yoder in his research and documented in a book called analysis patterns by Martin Fowler
In the Design phase, there are reusable components called design patterns and application patterns. Some of these are domain specific many are implementation type specific, others are generic.
Example: suppose you are doing a client server which you have 4500 clients using the system. You have an entity class for each of the tables in your system because you used the database pattern. (good choice). You now don’t want 4500 instances of the database open so you decide to use a database pooling pattern to NOT bring down the system by so many database opens, reads and writes waiting.
You might also decide on the pattern need to call the servelts if needed./
You might also decide on what pattern you will use for your session management, or perhaps you will use something like .net or webspere.
During code and test there are certainly programming patterns
Such as iterators, security patterns provided. Many patterns
Identify Reusable Components
Informal Specification Formal Specifications Code

12. Component Based Development
Architecture for Software Reuse
Based on Object Orientation
Classes are stored in a library
When requirements are received,the first stop is the library
In order to use this paradigm, you must have an architecture allowing this component implementation. An oo language, ability to implement patterns,
Classes or components are stored in the library
When you begin reading the software requirements, you need to FIRST stop at the library and see if some analysis patterns exist for you to reuse, and this continues at each stage

13. Linear Model Characteristics
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.
l Users HATE to read documentation.
l If users read, they rarely understand documentation.
Programmers don't understand other programmers documentations.
Standards for documentation not clear although UML ordained.
These are the types of linear models popular.
Some of their characteristics
It represents a systematic method of doing things with some rigor in the types and standards for the deliverables.
It requires a partitioning of the project into distinct stages
Remember that the stages really get to be multiple projects in various phases once subsystems are defined. The is especially evident when programming is done.
A large system may have 4500 programs we certainly are not going to hold up development waiting on coding of all These 4500 may all go thorough the cycle with various schedule times.
Difficult to respond to changes as the concurrent partitioned stages get complex and may be tightly coupled with data and processes of another concurrent cluster. \
MUCH documentation required
Users don’t always read documentation
Standards not clear even with UML

14. Iterative Models Prototyping
Now we will investigate some of the circular models.
One of the most popular is the iterative prototyping model or evolutionary prototyping model. This particular model shown here is used in extreme programming.
We listen to customer
Build or revise the system evolving
Allow user to test this portion and
repeat

15. Evolutionary (Prototype) Model
ONLY A PART OF THE FULL SYSTEM
Software
Requirements
Analysis
Design
Code and Unit
Testing
Integration
and Test
Acceptance
Test
SSR
PDR
CDR
TRR
CRR
FCA
PCA
Build
Prototype PR
SRS
PDD
SDS
STP
A more elaborate version of this model is the evolutionary prototype model in which a portion or part of th system is sliced off and the appropriate stages are traversed.
This is more formal with time for reviews, etc unlike the extreme programming model
SIP
Series of Implementations of each PART

16. Evolutionary/Prototype Model
Issues
Process is not visible--Lack of process visibility
Systems are often poorly structured—Change tends to corrupt the structures
Special tools and techniques may be required—Special skills (e.g. in languages for rapid prototyping) may be required
Applicability
For small or medium-size interactive systems
For parts of large systems (e.g. the user interface)
For short-lifetime systems
These type of prototype iterative models work well for small systems, parts of a large system that are clearly defined, and short lived systems.
Like extreme programming technique, it is NOT scalable.
Heres the rub.
If all you want to do is develop a small system, a clearly defined portion of a large system or a short lived system YOU DO NOT need a process model, JUST DO IT.
Hmmm so anything would do for these types of systems. The problem is in LARGE Development.

17. Iterative Models RAD team #3 team #2 team #1 business modeling datap r c
& v b u s i n e m o d l g a t p r c
& v
team #1
business
modeling
data
process
application
generation
testing
&
turnover
The iterative models may have several teams working on various portions of the system, with different timelines, with different paradigms. These become a project management nightmare.
days
RAD

18. The Incremental Model calendar time increment 1 delivery ofs i d e g c o t S m / f r
increment 1
delivery of
1st increment a n l y s i d e g c o t
delivery of
increment 2
2nd increment a n l y s i d e g c o t
delivery of
increment 3
3rd increment a n l y s i d e g c o t
increment 4
Incremental systems are different. They have similarities with iterative models but
They usually require an analysis to divide the system into incremental delivery of an operational system. The iterative model may not be anything operational at ech of the iterations and may not have anything until the end. \\
The incremental model has an operational system at the end of each increment.
delivery of
4th increment
calendar time

19. Incremental Development Model
ONLY A PART OF THE FULL SYSTEM
Software
Requirements
Analysis
Design
Code and Unit
Testing
Integration
and Test
Acceptance
Test
SSR
PDR
CDR
TRR
CRR
FCA
PCA
SRS
SDS
STP
SIP
Can Determine a PART at any phase.

20. Characteristics of Incremental Model
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 Model
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 Simulation
Operational Prototype
Verification for Next Level
Developing
You begin by planning what you first want to tackle in the system.
It may be something operation or not.
It usually is the most risky portion of the software.
That selected portion of the software is then analyzed for risk and prototyped
After the prototype is built, it may be improved to be an operational prototype, OR the selected slice of the system may be simulated for performance issues, OR the slice may be developed
You then verify what the next slice or level will be.
You then evaluate the current slice.
Then the process begins with planning
Client Evaluation and Input

23. An Evolutionary (Spiral) Modelg R i s k A n a l y s i s
Prototyping C u s t o m e r C o m m u n i c a t i o n E n g i n e e r i n g C u s t o m e r E v a l i n C o n s t r u c t i o n
& R e l e a s e
The spiral model is made for risky system this model has a little more detail of the spiral. This model has evolved over time.
Note the planning, risk analysis, and prototyping are the same.
The engineering phase is added to allow for design decisions to be discussed.
The next phase is the construction/simulation/prototype/next level verification
The next phase is the customer evaluation
The next phase is a high level of customer communication to determine what the planning of the next phase will be.;
And input
Simulation/ Operational Prototype/Verification for the Next Level/Development

24. CleanRoom Approach Specification Incremental Development Planning
and Design
Statistical
Testing
Certification
Usage
Design
Here is a unique approach and has MANY open areas for research in behavioral modeling that has been long overlooked

25. V Model [Pfleeger 98] OPERATION Validate requirements REQUIREMENTS
& MAINTENANCE
ANALYSIS
ACCEPTANCE
TESTING
SYSTEM
DESIGN
SYSTEM
Verify design
TESTING
PROGRAM
UNIT & INTE-
DESIGN
GRATION TESTING
While this approach was perhaps understood by most software engineers.
But this model clearly showed the relatinship of testing and the other phases
CODING
[Pfleeger 98]

26. Operational Specification Model
[Pfleeger 98]
Execute and
Revise
OPERATIONAL
TRANSFORMED
SPECIFICATION
SPECIFICATION
TEST
(problem-oriented)
(implementation-
oriented)
This is the simplist form used (with iterations) by the extreme programming techniques.
DELIVERED
SYSTEM
SYSTEM
REQUIREMENTS
(sometimes informal
or incomplete)

27. Still Other Process Models
Concurrent process model—recognizes that different part of the project will be at different places in the process
Formal methods—the process to apply when a mathematical specification is to be developed

28. Formal Method Characteristics
Formal Methods Model Specifications produce proofs
Required rigorous notation
Enhances accuracy
Reduces flexibility
Some Formal Methods Petri Nets, Zed, Hoare Logic, CSP, Weakest Preconditions
Formal Methods Abstraction
Add formality to reduce ambiguity Use graphical representations Describe the possible system states, transitions, and triggers

29. Capability Maturity Model
Organizations are not born using a mature process model.
Most organizations use NO known process model
Watts Humphrey wrote a book to lay out a plan for improving the process model within organizations. His book “Managing the Software Process” and other research has greatly improved the software engineering process.
The SEI Developed a capability maturity model which proposes a model for maturing an organizations process model.

30. Capability Maturity Model
Five Process Maturity Levels
Level 0: Chaos
Level 1: Initial
Level 2: Repeatable
Level 3: Defined
Level 4: Managed
Level 5: Optimizing

31. Level 1: Initial
The software process is characterized as ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual effort.

32. Level 2: Repeatable
Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications

33. Process Maturing to Level 2
Software configuration management
Software quality assurance
Software subcontract management
Software project tracking and oversight
Software project planning
Requirement management

34. Level 3: Defined
The software process for both management and engineering activities is documented, standardized, and integrated into an organization-wide software process. All projects use a documented and approved version of the organization’s process for developing and maintaining software.
This level includes all characteristics defined for level 2.

35. Process Maturing Level 3
Peer Reviews
Inter-group coordination
Software product engineering
Integrated software management
Training program
Organization process definition
Organization process focus

36. Level 4: Managed
Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled using detailed measures.
This level includes all characteristics defined for level 3.

37. Process Maturing Level 4
Software quality management
Quantitative process management

38. Level 5: Optimizing
Continuous process improvement is enables by quantitative feedback from the process and from testing innovative ideas and technologies
This level includes all characteristics defined for level 5.

39. Process Maturing Level 5
Process change management
Technology change management
Defect prevention

40. CMM Issues
focuses on project management rather than product development.
ignores the use of technologies such as rapid prototyping.
does not incorporate risk analysis as a key process area
does not define its domain of applicability