1. Software Development Process
소프트웨어 공학 원리 (SEP521)
Software Development Process
Jongmoon Baik

2. Software Development Processes (Lifecycle Models)

3. Operation & Maintenance
What is a S/W Life Cycle?
“The series of stages in form and functional activity through which an organism passes between successive recurrence of a specified primary stage” – Webster (1982)
“Period of time that begins when a software product is conceived and ends when the product is retired from use” – Don Reifer (1997)
Conversion
Development Stage
Ideally using S/W development process model (methodology)
Operation & Maintenance
Ideally using chosen technologies
- The software lifecycle is the cradle to grave existence of a software product or software intensive system
includes initial development, repairs, and enhancement, and decommission
Management of the entire lifecycle of a software intensive system requires a deeper knowledge than basic in-the-small development intuition and experience
Life-cycle process is a logical flow of activity representing an orderly progression from the identification of a mission need to final operational development and support
Lifecycle models attempt to generalize the software development process into steps with associated activities and/or artifacts.
They model how a project is planned, controlled, and monitored from inception to completion.
Lifecycle models provide a starting point for defining what we will do.
Obsolescence

4. What is Software Process?
Software process – a set of activities, methods, best practices, deliverables, and automated tools that stakeholders use to develop and continuously improve software.
Using a consistent process for software development:
Create efficiencies that allow management to shift resources between projects
Produces consistent documentation that reduces lifetime costs to maintain the systems
Promotes quality

5. What is S/W Process (Life Cycle) Model?
Software Process Model
An abstract representation of a process
A description of a process from some particular perspective
Attempt to generalize the s/w development process into steps with associated activities and/or artifacts
Proliferation of S/W Process Models
Provides flexibility for organizations to deal with the wide variety of software project situations, cultures, and environments
Weakens the defenses against some common sources of project failure
Each stage of the software process is identified and a model is then employed to represent the inherent activities associated with that stage
Examples of models
Workflow model: shows the sequence of activities (human actions) in the process along with their input, output, and dependencies
Dataflow model: represents the process as a set of activities each of which carries out some data transformation (e.g. shows how the input (specification) is transformed to the output (design). The activities (transformation carried out by people or computer) here may be lower than in a workflow model
Role model: represents the role of people involved in the software process and activities for which they are responsible

6. Process = Lifecycle
Software process is not the same as life cycle models.
process refers to the specific steps used in a specific organization to build systems
indicates the specific activities that must be undertaken and artifacts that must be produced
process definitions include more detail than provided lifecycle models
Software processes are sometimes defined in the context of a lifecycle model.

7. A Generic Process Model
- Schematic representation of a software process – Figure
Each software engineering action is defined by a task set that identifies the work tasks to be completed, the work products that will be produced, the quality assurance points that will be required, and the milestones that will be used to indicate progress.
Five framework activities : communication, planning, modeling, construction, and deployment
Umbrella activities : project tracking and control, risk management, quality assurance, configuration management, technical reviews, and others

8. Process Flow
- Process flow describes how the framework activities and actions and tasks that occur within each framework activity are organized with respect to sequence and time
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.

9. Identifying a Task Set
A task set defines the actual work to be done to accomplish the objectives of a software engineering action.
A list of the task to be accomplished
A list of the work products to be produced
A list of the quality assurance filters to be applied
You should choose a task set that best accommodates the needs of the project and the characteristics of your team. – process adoptation (tailoring).

10. 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 [Amb98] — 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.

11. Process Pattern Types
Stage patterns—defines a problem associated with a framework activity for the process.
e.g.: EstablishingCommunication
Task patterns—defines a problem associated with a software engineering action or work task and relevant to successful software engineering practice
e.g. : RequirementGathering
Phase patterns—define the sequence of framework activities that occur with the process, even when the overall flow of activities is iterative in nature.
e.g.: SpiralModel or Prototyping
A stage pattern incorporates with multiple task patterns. EstablishingCommunication incorporates with the task pattern RequirementGathering.

12. Generic S/W Process Models
Build-And Fix Model
Waterfall Model
Process phases are distinct and separate
Evolutionary Development
Process phases are interleaved
Formal Systems Development
A mathematical system model is formally transformed to an implementation
Component-Based Development
The system is assembled from existing components
Most of life cycle methodologies include at least the following:
Phases: the methodology should divide the life cycle into phases, which activities fall in each and include a process for determining when each system component can move to the next phase
Milestones : event-driven,, rather than schedule for cost-driven. Specify appropriate deliverables (a written report, briefing, test result, portion of code, or analysis 7 design data)
Content of deliverables: the methodology should define, either by topic or outline. What each milestone deliverable should include
Evaluation criteria for deliverables: the methodology should define what criteria a deliverable must meet for formal acceptance (as exit criteria for completion of the phase)

13. Need to look at with respect to:
Scope, Time, Resources, Quality
(remember these throughout the course)
Stakeholders
Environments
Business / Market
Cultures
Moral, legal constraints …

14. So, when looking at projects
Need to ask:
“What SDLC would fit my project best?”
(Is this better than what type of project would fit each SDLC?)

15. Prescriptive Models
Prescriptive process models advocate an orderly approach to software engineering
That leads to a few questions …
If prescriptive process models strive for structure and order, are they inappropriate for a software world that thrives on change?
Yet, if we reject traditional process models (and the order they imply) and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work?
There are a lot of prescriptive process models originally proposed to bring order to the chaos of software development.
Brought a certain amount of useful structure to software engineering work
Provided a reasonably effective roadmap for software teams

16. Build-And-Fix Model The worst (Ad Hoc) model for a software project
Become a mess, chuck it, start over
No proper specifications and design steps
Discouraged from using this model
Build First Version
Modify until client
is satisfied
In essence, the product is built and modified as many times as possible until it satisfies the client.
The cost of using this approach is greater than if specifications are drawn up and a design is carefully developed.
Software engineers are strongly discouraged from using this development approach. 
Maintenance

17. Waterfall Model Development flows steadily through:
requirements analysis, design implementation, testing, integration, and maintenance.
Formal “Sign-off” at the end of each phase
Documentation as product of each phase – Document-driven approach
Referred to as the linear sequential model or the software life cycle
The first software development process model
The waterfall model derives its name due to the cascading effect from one phase to the other as is illustrated in the figure
The first documented model by Winston Royce[1970]
two primary enhancements: feedback loops b/w stages, “build it twice” step parallel w/ requirement analysis
“Build it twice” : developing the core parts of an application twice
Royce advocated iterations of waterfalls adapting the results of the precedent waterfall
There are many variations of the waterfall model that contains essential activities, specification, design, code, test and operation/maintenance
Document-driven model approach
It was further popularized in a version that contained verification, validation or test activity at the end of each phase to ensure that the objectives of the phase were satisfied [Boehm 1976]

18. Waterfall Model: Advantages
Clear progress state
Good for project Management
Engineers know their tasks
Development is (relatively) slow and deliberate
Results in solid, well-constructed systems
All sub-goals within each phase must be met
Testing is inherent to every phase
- Technology had some influence on the viability of the waterfall model.
slow code, compile, and debug cycles
- Reflected the way that other engineering disciplines build things.
- Formed the basis of the earliest software process frameworks
Waterfall is still used today (but no one will admit it)
Real projects rarely follow the sequential flow that the model proposes.
It is often difficult for the customer to state all requirements explicitly.
The customer must have patience. A working version of the program will not be available until late in the project time span.

19. Waterfall Model : Drawbacks
Difficult (Expensive) to accommodate change after process is underway
One phase has to be complete before moving to the next phase
Inflexible partitioning of the project into distinct stages
Difficult to respond to changing customer requirements
Few business systems have stable requirements
Waterfall Problems
Increasing use of resources?
Oops
Go back to a previous step
Progressively more costly
Downside: Cost, Time, Cascading Bugs
Where appropriate?
It is a sequential document-driven approach, which is impractical for large projects due to shifting requirement.
A lack of user involvement, ineffectiveness in the requirement phase, inflexibility to accommodate, unrealistic separation of specification from design, gold plating, inflexible point solutions, inability to accommodate reuse, and various maintenance related problems.

20. Applicability of Waterfall Model
Therefore, Waterfall model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process
Mostly used for large software system projects where a system is developed at several sites

21. Evolutionary Development - I
McCracken and Jackson in 1983: developed to address deficiencies in the waterfall model related to having fully elaborated specification
The stages in the evolutionary model are expanding increments of an operation product, with evolution being determined by operational experience.

22. Evolutionary Development - II
Basic Idea
Build prototype version of system, seek use comments, and keep refining until done
Other side of formality spectrum from Waterfall Model
Prototyping a process whereby the developer create a quick working model of the software to be built
It is similar to the “build it twice” step in Royce’s 1970 initial waterfall model.
Produces a full-scale model and functional form of a new system, but only the part of interest
Used when there is only a general set of objectives, or other uncertainties exist about algorithmic efficiencies, or the desired form of interface

23. Two Flavors of Evolutionary Dev.
Exploratory development:
Objective is to work with customers and to evolve a final system from an initial outline specification (prototype)
Should start with well-understood requirement and add new features as proposed by the customer
Throw-prototyping
Objective is to understand the system requirements
Should start with poorly understood requirements to clarify what is really needed

24. Evolutionary Development: Advantages
Faster system development than with waterfall model
Useful when requirements are less-well understood
Customer inputs throughout development yields system closer to their needs
Steady visible signs of progress
Deliver an initial operational capability and provides a real world operational basis for evolution
Useful to deal with requirement changes rapidly (requirement creep)

25. Evolutionary Dev.: Drawbacks
Lack of process visibility
Not known how long it will take to create an acceptable product
Not known how many iteration will be necessary
Systems are often poorly structured
Continuous reflection of customer needs
Special skills (e.g. in languages for rapid prototyping) may be required.

26. Applicability of Evolutionary Dev.
For small or medium-size interactive systems
For parts of large systems (e.g. the user interface)
For short-lifetime systems

27. Formal Systems Development - I
Based on the transformation of a mathematical specification through different representations to an executable program
Transformations are ‘correctness-preserving’ so it is straightforward to show that the program conforms to its specification
Embodied in the ‘Cleanroom’ approach to software development
Each transformation should be sufficiently close to avoid excessive verification efforts and reduce the possibility of transformation errors
Like waterfall, the formal approach has clearly defined cascading phase boundaries
The objective of the Cleanroom methodology is to achieve or approach zero defects with certified reliability.
As described by Hausler (1994), the Cleanroom methodology provides a complete discipline within which software personnel can plan, specify, design, verify, code, test and certify software.
In a Cleanroom development, correctness verification replaces unit testing and debugging. After coding is complete, the software immediately enters system test with no debugging.
All test errors are accounted for from the first execution of the program with no private testing allowed.
As opposed to many development processes, the role of system testing is not to test in quality; the role of system testing is to certify the quality of the software with respect to the systems specification.
This process is built upon an incremental development approach

28. Formal Systems Development - II
Iteration and maintenance links are not shown in the diagram
R1, 2, 3: Refined Specifications by transformation stages T1, 2, 3
P1, 2, 3, 4: Transformation Programs

29. Formal Systems Dev.: Advantages
Transformations are small, making verification tractable
Resulting implementations are proven to meet specifications, so testing (of components) is unnecessary
Although, overall system characteristics (e.g. performance, reliability) still need verification -

30. Formal Systems Dev.: Drawbacks
Need for specialised skills and training
Expertise for the mathematical notations used for formal specifications
Development time high (usually not worth the time/cost)
No significant quality or cost advantages over other approaches
Difficult to formally specify some aspects of the system, e.g. user interfaces

31. Applicability of Formal Systems Dev.
Critical systems
Systems that require strict safety, reliability, and security requirements
Critical components within large systems

32. Component-Based Development - I
Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems
Process stages
Component analysis
Requirements modification
System design with reuse
Development and integration
This approach is becoming more important but still limited experience with it

33. Component-Based Development - II

34. Process iteration
System requirements ALWAYS evolve in the course of a project so process iteration where earlier stages are reworked is always part of the process for large systems.
Iteration can be applied to any of the generic process models.
Two (related) approaches
Incremental Model
Spiral Model

35. Incremental Model
Rather than deliver the system as a single delivery, the development and delivery is broken down into increments (Builds) with each increment delivering part of the required functionality.
Each increments provides more functionality than the previous increment
User requirements are prioritized and the highest priority requirements are included in early increments.
Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve.
How is this different from Evolutionary?

36. Incremental development
Implement and test
first build
Implement, integrate and test
successive build until product
is complete
Maintenance
Series of incremental builds until the product is finished
Value assignment to each build not yet implemented
Cost estimation of developing each build
Value-to-Cost ratio is the criterion used for next build selection
At each stage of the IM a new build is coded and then integrated into the structure, which is tested as a whole.
Note that the product is only defined as finished when it satisfies all of its requirements.
Combination of the elements of the waterfall model with the iterative philosophy of prototyping (A prototype is a working model that is functionally equivalent to a component of the product)
Unlike prototyping the IM focuses on the delivery of an operational product at the end of each increment
E.g. Word processing application
Basic file management, editing, and document production functions
Advanced editing and document production functions
Spell and grammar checking
Advance page layout, etc.

37. Incremental Model: Advantages
Customer value can be delivered with each increment so system functionality is available earlier.
Early increments act as a prototype to help elicit requirements for later increments.
Lower risk of overall project failure.
The highest priority system services tend to receive the most testing.

38. Spiral Model - I
Represented as a spiral rather than as a sequence of activities with backtracking.
Combines the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model
Provides the potential for rapid development of incremental versions of software
Each loop in the spiral represents a phase in the process.
No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required.
Risks are explicitly assessed and resolved throughout the process.
Combines evolutionary, incremental, and prototyping models
The goal is to identify risk, focus on it early.
In theory, risk is reduced in outer spirals a the product becomes more refined.
Each spiral
starts with design goals
ends with the client reviewing the progress thus far and future direction
was originally prescribed to last up to 2 years
[Boehm 1988]: “A Spiral Model of Software Development and Enhancement”

39. Spiral Model - II
The evolutionary process begins at the centre position and moves in a clockwise direction. Each traversal of the spiral typically results in a deliverable. For example, the first and second spiral traversals may result in the production of a product specification and a prototype, respectively. Subsequent traversals may then produce more sophisticated versions of the software.
An important distinction between the spiral model and other software models is the explicit consideration of risk. There are no fixed phases such as specification or design phases in the model and it encompasses other process models. For example, prototyping may be used in one spiral to resolve requirement uncertainties and hence reduce risks. This may then be followed by a conventional waterfall development.
·        Note that each passage through the planning stage results in an adjustment to the project plan (e.g. cost and schedule are adjusted based on the feedback from the customer, project manager may adjust the number of iterations required to complete the software….)
·        Each of the regions is populated by a set of work tasks called a task set that are adapted to characteristics of the project to be undertaken. For small projects the number of tasks and their formality is low. Conversely, for large projects the reverse is true.

40. Spiral Model Sectors - I
Determine objectives, alternatives, & constraints
Specific objectives for the phase (performance, functionality, ability to accommodate changes etc.)
Alternative means of implementing this portion of the product (design A, design B, reuse, buy, etc.)
Constraints imposed on the application of the alternatives (cost, schedule, interface, etc.)
Evaluate Alternatives, Identify, resolve risks
Evaluate alternatives relative to the objectives and constraints
Identify areas of uncertainty that significant sources of project risk
Formulate a cost effective strategy for resolving sources of risk
Prototyping, simulation, benchmarking, reference checking, administering user questionnaires, analytic modeling, or combinations of these and other resolution techniques

41. Spiral Model Sectors - II
Develop, Verify next-level product
A development model for the system is chosen which can be any of the generic models.
Evolutionary model, waterfall model, incremental development, combinations, etc.
Plan Next Phases
The project is reviewed and the next phase of the spiral is planned
The review covers all products developed during the previous cycle, plans for the next cycle, resource required
Ensure that all concerned parties are mutually committed to the approach for the next phase
- Evolutionary model: if performance or user interface risks strongly dominate program development or internal interface control risks: minimal effort to specify the overall nature of the product
- Waterfall combined with incremental development: if previous prototyping efforts have alredy resolved all of performance or user-interface risks, and program development or interface-control risk dominates
This risk-driven sub-settings of the spiral model steps allows the model to accommodate any appropriate mixture of a specification-oriented, prototype-oriented, simulation-oriented, automatic transformation-oriented, or other approached to software development.

42. Six Spiral Model Essentials
1. Concurrent determination of artifacts in each cycle
2. Each cycle addresses objectives, constraints, alternatives, risks, artifact elaboration, stakeholders’ commitment
3. Risk-driven activity level of effort
4. Risk-driven artifact degree of detail
5. Managing stakeholder commitments via anchor-point milestones
6. Emphasis on system and life-cycle issues
- vs. software and development issues

43. Spiral Model : Advantages
The spiral model is a realistic approach to the development of large-scale software products because the software evolves as the process progresses. In addition, the developer and the client better understand and react to risks at each evolutionary level.
The model uses prototyping as a risk reduction mechanism and allows for the development of prototypes at any stage of the evolutionary development.
 It maintains a systematic stepwise approach, like the classic life cycle model, but incorporates it into an iterative framework that more reflect the real world.
If employed correctly, this model should reduce risks before they become problematic, as consideration of technical risks are considered at all stages.
Disadvantages of the Spiral Model
·        Demands considerable risk-assessment expertise
·        It has not been employed as much proven models (e.g. the WF model) and hence may prove difficult to ‘sell’ to the client (esp. where a contract is involved) that this model is controllable and efficient. [More study needs to be done in this regard]

44. IBM-UP Model - I
IBM-UP (Unified Process)
A modern process model derived from the work on the UML and associated process.
Normally described from 3 perspectives
A dynamic perspective that shows phases over time
A static perspective that shows process activities
A proactive perspective that suggests good practice

45. IBM-UP Model - II The inception phase
In this phase the business case which includes business context, success factors (expected revenue, market recognition, etc), and financial forecast is established. To complement the business case, a basic use case model, project plan, initial risk assessment and project description (the core project requirements, constraints and key features) are generated. After these are completed, the project is checked against the following criteria:
Stakeholder concurrence on scope definition and cost/schedule estimates.
Requirements understanding as evidenced by the fidelity of the primary use cases.
Credibility of the cost/schedule estimates, priorities, risks, and development process.
Depth and breadth of any architectural prototype that was developed.
Actual expenditures versus planned expenditures.
If the project does not pass this milestone, called the Lifecycle Objective Milestone, it can either be cancelled or it can repeat this phase after being redesigned to better meet the criteria.
[edit]
The elaboration phase
The elaboration phase is where the project starts to take shape. In this phase the problem domain analysis is made and the architecture of the project gets its basic form.
This phase must pass the Lifecycle Architecture Milestone by meeting the following criteria:
A use-case model in which the use-cases and the actors have been identified and most of the use-case descriptions are developed. The use-case model should be 80% complete.
A description of the software architecture in a software system development process.
An executable architecture that realizes architecturally significant use cases.
Business case and risk list which are revised.
A development plan for the overall project.
If the project cannot pass this milestone, there is still time for it to be cancelled or redesigned. After leaving this phase, the project transitions into a high-risk operation where changes are much more difficult and detrimental when made.
The construction phase
In this phase the main focus goes to the development of components and other features of the system being developed. This is the phase when the bulk of the coding takes place.
This phase produces the first external release of the software. Its conclusion is marked by the Initial Operational Capability (IOC) milestone.
The transition phase
In the transition phase the product has moved from the development organization to the end user. The activities of this phase include training of the end users and maintainers and beta testing of the system to validate it against the end users' expectations. The product is also checked against the quality level set in the Inception phase. If it does not meet this level, or the standards of the end users, the entire cycle in this phase begins again.
If all objectives are met, the Product Release (PR) milestone is reached and the development cycle ends.

46. Best practices of UP Develop software iteratively Manage requirements
Use component based architecture
Visually model software
Verify software quality
Control changes to software

47. High Adopting UP is often thought to be expensive.
Limitations of UP
High Adopting UP is often thought to be expensive.
Does not cover any non-software aspects of development
e.g., system engineering. product-line engineering, safety engineering
Considered too practical, as the practicality has been based on current status of the IBM tool suite

48. V Model - I
Often used in system engineering environments to represent the system development lifecycle.
summarizes the main steps taken to build systems not specifically software
describes appropriate deliverables corresponding with each step in the model.

49. V Model - II
The left side of the V: the specification stream where the system specifications are defined.
The right side of the V: the testing stream where the systems is being tested against the specifications defined on the left side.
The bottom of the V where the tails meet, represents the development stream.

50. Current State of the Art
Iterative, cyclic development
Agile Processes? – covered later
Software is grown rather than birthed whole
Short cycles, Small teams
Component development (Reuse, COT, Product Line, etc)
More integration vice new development (SoS)?
When looking at a new project,
DO NOT make your project fit a SDLC!!!
INSTEAD, find the right SDLC and tailor it to your project (if it can be).
Your organization may drive this
But any lifecycle, process should be seen as a tool to assist development, not an end in and of it self.
As a program manager, you must be prepared to develop a tailored management approach that will achieve an operational capability with the most effective use of resources and time available.
Choosing the right life cycle management methodology for your program depends on the nature of its operational environment, stability of requirements and technology, your software domain, the methods and tools used, and the controls and deliverables required.

51. Process Model Decision

52. Process Assessment and Improvement
Standard CMMI Assessment Method for Process Improvement (SCAMPI) — provides a five step process assessment model that incorporates five phases: initiating, diagnosing, establishing, acting and learning.
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 [Dun01]
SPICE—The SPICE (ISO/IEC15504) standard defines a set of requirements for software process assessment. The intent of the standard is to assist organizations in developing an objective evaluation of the efficacy of any defined software process. [ISO08]
ISO 9001:2000 for Software—a generic standard that applies to any organization 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. [Ant06]
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.

53. Personal Software Process (PSP)
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 constructed are developed and a component design is created. Prototypes are built when uncertainty exists. All issues are recorded and tracked.
High-level design review. Formal verification methods (Chapter 21) 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 substantial amount of data that should be analyzed statistically), the effectiveness of the process is determined. Measures and metrics should provide guidance for modifying the process to improve its effectiveness.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.

54. Team Software Process (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 (IPT) of three 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.
The Capability Maturity Model (CMM), a measure of the effectiveness of a software process, is discussed in Chapter 30.
Provide improvement guidance to high-maturity organizations.
Facilitate university teaching of industrial-grade team skills.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.

55. Standard Processes IEEE and ISO Software Engineering Standards
IEEE Standard for Developing Software Life Cycle Processes
(R2004)IEEE Standard for Information Technology - Software Life Cycle Processes - Reuse Processes
IEEE/EIA Standard: Industry Implementation of International Standard ISO/IEC 12207:1995 Standard for Information Technology--Software Life Cycle Processes.
IEEE Std (Adoption of ISO/IEC 15288:2002, IDT), Systems Engineering---System Life Cycle Processes
………

56. Q & A