Software Engineering & Project Management

BCS501 (3:0:0)

Software Engineering: A Practitioners Approach – Roger S. Pressman, 7th Edition, McGraw-Hill

2010

COs Course Outcomes Bloom’s level

Describe the fundamentals of Software Engineering Process and Process

CO1 Understand
Models.
CO2 Discuss requirement engineering tasks. Understand
CO3 Prepare quality software system using design principles. Apply

CO4 Use software testing techniques to perform system validations. Apply

Apply an effective software project estimation model for developing software

CO5 Apply
product.
 Overview
➢Introduction to Software engineering
➢The Software Process: Software Engineering
➢ A Layered Technology
➢ A Process Frame Work
➢ Capability Maturity Model Integration
➢Process Models: Incremental Process Models, Evolutionary
Process Models
 Introduction to Software Engineering
• Software: Computer programs and associated documentation., different types of software
• Definition of Software Engineering(IEEE definition)
• Software engineering is the application of a systematic, disciplined, quantifiable approach to
the development, operation, and maintenance of software; that is, the application of
engineering to software
• Software engineering is an engineering discipline that is concerned with all aspects of
software production from the early stages of system specification through to
maintaining the system after it has gone into use.
• Today, seven broad categories of computer software present continuing challenges for software
engineers(Software Application Domains)
1. System software
2. Application software
3. Engineering/scientific software: Ex:Computer-aided design, system simulation
4. Embedded software-Ex: Fuel Control, dashboard display &braking systems
5. Product-line software-Ex:word processing, spreadsheets, computer graphics, multimedia,
entertainment, database management.
6. Web applications
7. Artificial intelligence software:Ex:robotics, expert systems.
Introduction to Software Engineering Cont..
• Legacy Software:Dayani-Fard and his colleagues [Day99] describe
legacy software in the following way:
• 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
• Software engineering is a layered technology. Referring to Figure 1,
any engineering approach (including software engineering) must rest
on an organizational commitment to quality
 A Layered Technology
Quality Focus: The bedrock that supports
software engineering is a quality focus.
Process: The foundation for software
engineering is the process layer. Process defines
a framework,that must be established for
effective delivery of software engineering
technology.
Methods: Software engineering methods
Figure 1:Software engineering layers provide the technical how-to’s for building
software. Methods encompass a broad array of
tasks that include communication, requirements
analysis, design modeling, program
construction, testing, and support.
Tools: Software engineering tools provide
automated or semiautomated support for the
process and the methods.
 Software Process
• A process is a collection of activities, actions, and tasks that are performed when some work
product is to be created.
• 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. In addition, the process framework encompasses a set of
umbrella activities that are applicable across the entire software process.
A generic process framework for software
engineering encompasses five activities:
1. Communication
2. Planning
3. Modelling
4. Construction
5. Deployment.
Typical umbrella activities include:
1. Software project tracking and control
2. Risk management.
3. Software quality assurance
4. Technical reviews
5. Measurement.
6. Software configuration management
7. Reusability management.
8. Work product preparation and production Figure 2: Generic software process framework
 Software Engineering Practice(SEP)
• In the previous slide, we introduced a generic software process model
composed of a set of activities that establish a framework for
software engineering practice. Generic framework activities—
communication, planning, modeling, construction, and deployment—
and umbrella activities establish a skeleton architecture for software
engineering work.
• In SEP a basic understanding of the generic concepts and principles
that apply to framework activities will be understood.
• Understand the problem (communication and analysis)
• Plan a solution (modeling and software design).
• Carry out the plan (code generation).
• Examine the result for accuracy (testing and quality assurance).
 Capability Maturity Model Integration(CMMI)
• The original CMM was developed and upgraded
by the Software Engineering Institute
throughout the 1990s as a complete SPI
framework. Today, it has evolved into the
Capability Maturity Model Integration (CMMI)
[CMM07], a comprehensive process meta-
model that is predicated on a set of system and
software engineering capabilities that should be
present as organizations reach different levels of
process capability and maturity.
• The CMMI represents a process meta-model in
two different ways: (1) as a “continuous” model
and (2) as a “staged” model. The continuous
CMMI metamodel describes a process in two
dimensions as illustrated in Figure 3.
• Each process area (e.g., project planning or
requirements management) is formally assessed
against specific goals and practices and is rated Figure 3: CMMI process area capability profile.
according to the following capability levels
 Capability Maturity Model Integration(CMMI) Cont..
• Level 0: Incomplete—the process area (e.g., requirements management) is either not
performed or does not achieve all goals and objectives defined by the CMMI for level 1
capability for the process area.
• Level 1: Performed—all of the specific goals of the process area (as defined by the
CMMI) have been satisfied. Work tasks required to produce defined work products are
being conducted.
• Level 2: Managed—all capability level 1 criteria have been satisfied. In addition, all
work associated with the process area conforms to an organizationally defined policy; all
people doing the work have access to adequate resources to get the job done;
stakeholders are actively involved in the process area as required; all work tasks and
work products are “monitored, controlled, and reviewed; and are evaluated for adherence
to the process description.
• Level 3: Defined—all capability level 2 criteria have been achieved. In addition, the
process is “tailored from the organization’s set of standard processes according to the
organization’s tailoring guidelines, and contributes work products, measures, and other
process-improvement information to the organizational process assets.
 Capability Maturity Model Integration(CMMI) Cont..
• Level 4: Quantitatively managed—all capability level 3 criteria have been achieved. In
addition, the process area is controlled and improved using measurement and quantitative
assessment. “Quantitative objectives for quality and process performance are established
and used as criteria in managing the process” [CMM07]
• Level 5: Optimized—all capability level 4 criteria have been achieved. In addition, the
process area is adapted and optimized using quantitative (statistical) means to meet
changing customer needs and to continually improve the efficacy of the process area
under consideration.
• The CMMI defines each process area in terms of “specific goals” and the “specific
practices” required to achieve these goals.
• Specific goals establish the characteristics that must exist if the activities implied by
a process area are to be effective.
• Specific practices refine a goal into a set of process-related activities.
 Capability Maturity Model Integration(CMMI) Cont..
• The staged CMMI model defines
the same process areas, goals, and
practices as the continuous model.
The primary difference is that the
staged model defines five maturity
levels, rather than five capability
levels. To achieve a maturity level,
the specific goals and practices
associated with a set of process
areas must be achieved. The
relationship between maturity
levels and process areas is shown in
Figure 4.

Figure 4:Process areas required to achieve a maturity

level.
 Process Models
• 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 or
model that defines their relationship with
the process and with one another.
• Process flow—describes how the
framework activities and the actions and
tasks that occur within each framework
activity are organized with respect to
sequence and time and is illustrated in
Figure 5.

Figure 5: Process flow

 Software Process Model
• Prescriptive(Traditional) process models
• Water Fall Model
• The V-model
• Incremental Process Models
• Evolutionary Process Models
• Prototyping
• The Spiral Model
• Concurrent Models
• Agile Model(Module 2)
 Process Models Continued
• Water Fall Model
• (Proposed by Winston Royce [Roy70]

Figure 6: The waterfall model(classic life cycle)

 Incremental Process Models
• The incremental model combines elements of linear
and parallel process flows.
• The incremental model applies linear sequences in a
staggered fashion as calendar time progresses. Each
linear sequence produces deliverable “increments” of
the software [McD93] in a manner that is similar to the
increments produced by an evolutionary process flow.
• 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.
• 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; and advanced page layout
capability in the fourth increment. It should be noted
that the process flow for any increment can Figure 7:The incremental model
incorporate the prototyping paradigm
 Evolutionary Process Models
• Evolutionary process models produce an increasingly more complete
version of the software with each iteration

• Prototyping
• The Spiral Model

Prototyping Model: Often, a customer defines a set of general objectives for

software, but does not identify detailed requirements for functions and features.
In other cases, the developer may be unsure of the efficiency of an algorithm, the
adaptability of an operating system, or the form that human-machine interaction
should take. In these, and many other situations, a prototyping paradigm may offer
the best approach
Figure 8: The prototyping paradigm
 Evolutionary Process Models Cont..
The Spiral Model
• Originally proposed by Barry Boehm [Boe88],
the spiral model is an evolutionary software
process model that couples the iterative
nature of prototyping with the controlled and
systematic aspects of the waterfall 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. Cost and schedule are adjusted based on
feedback derived from the customer after
delivery. In addition, the project manager Figure 9:A typical spiral model
adjusts the planned number of iterations
required to complete the software.
 Concurrent Models
• The concurrent development model,
sometimes called concurrent
engineering, allows a software team to
represent iterative and concurrent
elements of any of the process models.
• Figure 10 provides a schematic
representation of one software
engineering activity within the
modeling activity using a concurrent
modeling approach. The activity—
modeling—may be in any one of the
states12 noted at any given time.
Similarly, other activities, actions, or
tasks (e.g., communication or
construction) can be represented in an
analogous manner. All software Figure 10:One element of the concurrent
engineering activities exist concurrently process model
but reside in different states.