YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
Introduction to Software Engineering, Software Process, Perspective and Specialized
Process Models – Software Project Management: Estimation – LOC and FP Based
Estimation, COCOMO Model – Project Scheduling – Scheduling, Earned Value Analysis –
Risk Management.
Part A
1. What are the different phases of software engineering (APR/MAY/2010)
(NOV/DEC/2012)
 The definition phase focuses on what. That is, during definition, the software engineer
attempts to identify what information is to be processed, what function and performance are
desired, what system behavior can be expected, what interfaces are to be established, what
design constraints exist, and what validation criteria are required to define a successful
system.
 The development phase focuses on how. That is, during development a software engineer
attempts to define how data are to be structured, how function is to be implemented within a
software architecture, how procedural details are to be implemented, how interfaces are to be
characterized, how the design will be translated into a programming language (or
nonprocedural language), and how testing will be performed.
 The support phase focuses on change associated with error correction, adaptations required
as the software's environment evolves, and changes due to enhancements brought about by
changing customer requirements
2. Define software process model (APR/MAY/2010)
The software process model can be defined as an abstract representation of process. The
software process model consists of various process activities, role of people involved in process
development and software product
3. What is the main difference between system engineering and software engineering
(NOV/DEC/2010)
Software Engineering
 Software engineering is an engineering discipline that is concerned with all aspects of
software production.
 Software engineers should adopt a systematic and organised approach to their work and
use appropriate tools and techniques depending on the problem to be solved, the
development constraints and the resources available.
System Engineering
 System engineering is concerned with all aspects of computer-based systems
development including hardware, software and process engineering.
 System engineers are involved in system specification, architectural design,
integration and deployment.
 Software engineering is part of this process concerned with developing the software
infrastructure, control, applications and databases in the system.
4. State the complicating characteristics of computer bases systems (NOV/DEC/2010)
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 1
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
One complicating characteristic of computer-based systems is that the elements constituting
one system may also represent one macro element of a still larger system. The macro element is
a computer-based system that is one part of a larger computer-based system. As an example, we
consider a "factory automation system" that is essentially a hierarchy of systems. At the lowest
level of the hierarchy we have a numerical control machine, robots, and data entry devices. Each
is a computer based system in its own right. The elements of the numerical control machine
include electronic and electromechanical hardware (e.g., processor and memory, motors,
sensors), software (for communications, machine control, interpolation), people (the machine
operator), a database (the stored NC program), documentation, and procedures. A similar
decomposition could be applied to the robot and data entry device. Each is a computer-based
system
5. Define software engineering. What is the scope of software engineering
(APR/MAY/2011)
 Software Engineering is the establishment and the use of sound engineering principle in
order to obtain a reliable and efficient software.
OR
 Software engineering is a discipline in which theories, methods and tools are applied to
develop professional software product.
OR
 Systematic, disciplined, quantifiable approach to the development, operation and
maintenance of software. That is the application of engineering to software.
The key challenges facing software engineering are:
 Heterogeneity
o Developing techniques for building software that can cope with heterogeneous
platforms and execution environments;
 Delivery
o Developing techniques that lead to faster delivery of software;
 Trust (Copying with legacy systems)
o Developing techniques that demonstrate that software can be trusted by its users.
goals/ objectives of software engineering
 Satisfy user requirements.
 High reliability.
 Low maintenance costs.
 Delivery on time
 Low production costs.
 High performance.
 Ease of reuse.
6. What is meant by independent verification and validation (NOV/DEC/2011)
 Verification represents the set of activities that are carried out to confirm the software
correctly implements the specific functionality.
 Validation represents set of activities that ensure that the software that has been is satisfying
the customer requirements.
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 2
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
7. Differentiate waterfall model with V- model (NOV/DEC/2011)
 .In Waterfall Model the tester role will take place only in the test phase but in V-Model
role will take place in the requirement phase itself
 Waterfall model is a fixed process u can't make any changes in the requirement or in any
phase but in V-Model can make any changes in the requirements
 .V-model is the simultaneous process but it is not in case of water fall model
 .waterfall model used only when the requirements are fixed but V-model can be used for
any type of requirement(Uncertain requirement)
 Waterfall model
 V-model
8. Name the task regions of a spiral model (MAY/JUN/2012)
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 3
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
 A spiral model is divided into a number of framework activities, also called task regions.
Typically, there are between three and six task regions. Figure 2.8 depicts a spiral model
that contains six task regions:
 Customer communication—tasks required to establish effective communication
between developer and customer.
 Planning—tasks required to define resources, timelines, and other project related
information.
 Risk analysis—tasks required to assess both technical and management risks.
 Engineering—tasks required to build one or more representations of the application.
 Construction and release—tasks required to construct, test, install, and provide user
support (e.g., documentation and training).
9. What are different approaches to the sizing problem (MAY/JUN/2012)
We consider the software sizing problem. Because a project estimate is only as good as
the estimate of the size of the work to be accomplished, sizing represents the project
planner’s first major challenge. In the context of project planning, size refers to a quantifiable
outcome of the software project. If a direct approach is taken, size can be measured in LOC.
If an indirect approach is chosen, size is represented as FP.
 “Fuzzy logic” sizing
 Function point sizing
 Standard component sizing
 Change sizing
10. List the issues of software’s
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 4
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
There are three general issues that affect many different types of software:
• Heterogeneity Increasingly, systems are required to operate as distributed systems across
networks that include different types of computer and mobile devices we often have to
integrate new software with older legacy systems written in different programming
languages. The challenge here is to develop techniques for building dependable software that
is flexible enough to cope with this heterogeneity.
• Business and social change Business and society are changing incredibly quickly as
emerging economies develop and new technologies become available. They need to be able
to change their existing software and to rapidly develop new software. Many traditional
software engineering techniques are time consuming and delivery of new systems often takes
longer than planned. They need to evolve so that the time required for software to deliver
value to its customers is reduced.
• Security and trust. This is especially true for remote software systems accessed through a
web page or web service interface. We have to make sure that malicious users cannot attack
our software and that information security is maintained.
11. Define dynamic verification (NOV/DEC/2012)
 Dynamic verification is performed during the execution of software, and dynamically
checks its behaviour; it is commonly known as the Test phase. Verification is a Review
Process. Depending on the scope of tests, we can categorize them in three families:
 Test in the small: a test that checks a single function or class (Unit test)
 Test in the large: a test that checks a group of classes, such as
o Module test (a single module)
o Integration test (more than one module)
o System test (the entire system)
 Acceptance test: a formal test defined to check acceptance criteria for a software
o Functional test
o Non functional test (performance, stress test)
 Software verification is often confused with software validation. The difference
between verification and validation:
o Software verification asks the question, "Are we building the product right?"; that
is, does the software conform to its specification.
o Software validation asks the question, "Are we building the right product?"; that
is, is the software doing what the user really requires.
 The aim of software verification is to find the errors introduced by an activity, i.e. check
if the product of the activity is as correct as it was at the beginning of the activity.
12. State the human and organizational factors from the system’s environment that affect
the system design (MAY/JUN/2013)
 Communication: communicate with customer to understand objectives and gather
requirements

Planning: creates a “map” defines the work by describing the tasks, risks and resources,
work products and work schedule.
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 5
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT

Modeling: Create a “sketch”, what it looks like architecturally, how the constituent parts
fit together and other characteristics.

Construction: code generation and the testing.

Deployment: Delivered to the customer who evaluates the products and provides
feedback based on the evaluation
Organizational factors
 Software project tracking and control
 Risk management
 Software Quality Assurance
 Formal Technical Reviews
 Software Configuration Management
 Work product preparation and production
 Reusability management
 Measurement.
13. What are the umbrella activities of a software process?
 Software project tracking and control.
 Risk management.
 Software Quality Assurance.
 Formal Technical Reviews.
 Software Configuration Management.
 Work product preparation and production.
 Reusability management. Measurement.
14. Distinguish between spiral model from winwin spiral model (MAY/JUN/2013)
 The spiral model is similar to the incremental model, with more emphases placed on risk
analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and
Evaluation. A software project repeatedly passes through these phases in iterations (called
Spirals in this model). The baseline spiral, starting in the planning phase, requirements is
gathered and risk is assessed. Each subsequent spiral builds on the baseline spiral.
Requirements are gathered during the planning phase. In the risk analysis phase, a process is
undertaken to identify risk and alternate solutions. A prototype is produced at the end of the
risk analysis phase. Software is produced in the engineering phase, along with testing at the
end of the phase. The evaluation phase allows the customer to evaluate the output of the
project to date before the project continues to the next spiral.
 The original spiral model began each cycle of the spiral by performing the next level of
elaboration of the prospective system's objectives, constraints and alternatives. A primary
difficulty in applying the spiral model has been the lack of explicit process guidance in
determining these objectives, constraints, and alternatives. The Win-Win Spiral Model uses
the theory W (win-win) approach to converge on a system's next-level objectives,
constraints, and alternatives. This Theory W approach involves identifying the system's
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 6
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
stakeholders and their win conditions, and using negotiation processes to determine a
mutually satisfactory set of objectives, constraints, and alternatives for the stakeholders.
15. List the process maturity levels in SEIs CMM.
 Level 1:Initial – Few processes are defined and individual efforts are taken.
 Level 2:Repeatable – To track cost schedule and functionality basic project
management processes are established.
 Level 3:Defined – The process is standardized, documented and followed.
 Level 4:Managed – Both the software process and product are quantitatively
understood and controlled using detailed measures.
 Level 5:Optimizing – Establish mechanisms to plan and implement change.
16. What is an effectors process?
The effectors process is a process that verifies itself..The effectors process exists in certain
criteria.
17. Differentiate between verification and validation (NOV/DEC/2013)
(NOV/DEC/2014)(MAY/JUNE/2014)
OR
18. Distinguish between software validation and software verification (APR/MAY/2011)
Verification
Validation
1. Are we building the product right?
2. Verification shows conformance
with specification
1. Are we building the right product?
2. Validation shows that the program
meets the customer’s needs.
19. What do you mean by computer based system (NOV/DEC/2013)
The computer based system can be defined as “a set or an arrangement of elements that are
organized to accomplish some predefined goal by processing information”
20. Differentiate between Software Engineering and Computer Science
.
Software Engineering
Computer Science
The software engineering is concerned with
The computer science deals with the theories
the practical problems of producing software.
and methods used by the computers and
software systems.
Some knowledge of computer science is
Elegant theories cannot be completely
necessary for the software engineers to develop applicable to the software engineering when
the software.
software solution to complex or real world
problem has to be developed.
21. What are the steps followed in testing?
 Unit testing – The individual components are tested in this type of testing.
 Module testing – Related collection of independent components are tested.
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 7
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
 Sub-system testing – This is a kind of integration testing. Various modules are
integrated into a subsystem and the whole subsystem is tested.
 System testing – The whole system is tested in this system.
 Acceptance testing – This type of testing involves testing of the system with
customer data. If the system behaves as per customer need then it is accepted.
22. . What is the use of CMM?
Capability Maturity Model is used in assessing how well an organizations processes allow to
complete and manage new software projects.
23. Name the Evolutionary process Models.
i. Incremental model
ii. Spiral model
iii. WIN-WIN spiral model
iv. Concurrent Development
24. How to determine the costs in the software engineering.
The costs in the software engineering system depends upon- the type of software being
developed and the software process being used.
25. . How to create good software.
Essential attributes of good design:
Maintainability
Software should be written in such a way so that it can evolve to meet the changing needs
of customers. This is a critical attribute because software change is an inevitable requirement of a
changing business environment.
Dependability and security
Software dependability includes a range of characteristics including reliability, security,
and safety. Dependable software should not cause physical or economic damage in the event of
system failure. Malicious users should not be able to access or damage the system.
Efficiency
Software should not make wasteful use of system resources such as memory and
processor cycles. Efficiency therefore includes responsiveness, processing time, memory
utilization, etc.
Acceptability
Software must be acceptable to the type of users for which it is designed. This means that it
must be understandable, usable, and compatible with other systems that they use
26. What are software characteristics?
Software development is a logical activity and therefore it is important to understand
basic characteristics of software .Some important characteristics of software are ,
 Software is engineered, not manufactured.
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 8
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
 Software does not wear out.
 Most software is custom built rather than being assembled from components.
27. Define Verification and Validation.
Verification represents the set of activities that are carried out to confirm the software
correctly implements the specific functionality.
Validation represents set of activities that ensure that the software that has been is
satisfying the customer requirements.
28. What is system engineering?
System Engineering means designing, implementing, deploying and operating the systems
which include hardware, software and people
29. What are restraining factors for system model constructions?
 Assumptions
 Simplifications
 Limitations
 Constraints
 Preference
30. . What are goals of business process Engineering.
 The goal of business Process Engineering is to define such an architectures using which
information can be effectively used by the business.
 For satisfying business architecture and goals there are three different architectures that
can be analyzed and designed these are,
o Data architecture
o Applications architecture.
o Technology infrastructure.
31. . What are the goals of product engineering
 The goal of product engineering is to translate the customers demand working product.
 To achieve this goal architecture is built.
32. What is embedded system process.
The embedded system process is a process which works as a part of software model.
Embedded system process run on a single processor or an integrated group of processors.
33. Distinguish between process and methods.
Software process can be defined as the structured set of activities that are required to
develop the software system. Various activities under software process are.
 Specification
 Design and implementation
 Validation
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 9
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
 Evolution
Method is used mainly in object-oriented programming; the term method refers to a piece of
code that is exclusively associated either with an class or a object.
34. Why software architecture is important in software process
. The software architecture gives the hierarchical structure of software components and their
interactions .In software architecture the software model is designed and structure of that model
is partitioned horizontally or vertically .This helps in implementing a quality software product.
35. What are phases encompassed in the RAD model.
Various phases in the RAD model are
 Business modeling
 Data modeling
 Process modeling
 Application generation
 Testing and turnover
36. Which process model leads to software reuse? Why.
The object oriented model is used for the software reuse because –this model is based on the
incremental development of the software product. This can be done in one or more iterations.
37. What does system engineering model accomplish?
System engineering is modeling process. it accomplishes following things.
 The process that needs a view of consideration is defined.
 Behavior of the system.
 Exogenous and endogenous input is defined.
 All linkages for understanding each view must be represented.
38. Define software life cycle. And its types
Software life cycle is the period of time beginning with a concept for a software product and
ending whenever the software is no longer available for use.
Types of lifecycle model.
1. Prescriptive process model
2. Water fall model
3. Incremental process Model
i) Incremental Model
ii) RAD Model
4. Evolutionary process Model
i) Prototyping model
ii) Spiral Model
iii) The concurrent development Model
5. Specialized Process Model
i) Component based development Model
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 10
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
ii) Formal Methods Model
iii) Aspect oriented S/W development (AOSD)
6. Unified process model
39. Define Water fall model.
 It is an oldest model
 Sometimes called classic lifecycle model
 It is a systematic and sequential approach
 Start from communication and process through planning, modeling, construction and
deployment.
40. What are the Steps present in Waterfall model?
 Communication: Collaboration with customer, gathering information
 Planning: establish a work plan, describe technical risks, list resource, work products etc
 Modeling: creation of models, and design
 Construction: coed generation and testing
 Deployment: delivered to the customer ,evaluate, and provides a feedback
41. Drawbacks of waterfall model
 Oldest model. Rarely follows the sequential flow.
 Difficult to collect requirement explicitly at the beginning.
 A working version not available in later releases.
 It leads a blocking state.
42. What are the phases encompassed in RAD model?
a. Business modeling
b. Data modeling
c. Process modeling
d. Application generation
e. Testing
43. What is meant by development process?
A software development process is a structure imposed on the development of software
product which include analysis, design, code and Test.
44. Give at least two reasons for why prototyping is problematic.
 Prototyping model doesn’t consider the overall software quality or long term
maintainability.
 Developer uses an inappropriate operating system or programming language in orderto
get a prototype working quickly.
45. What are the advantages of prototyping model?
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 11
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
 Prototyping model is used when a customer defines a set of objectives for software but
doesn’t identify detailed input, processing and output requirements.
 It serves as the mechanism for identifying software requirements.
 If the prototype is built the developer attempts to use existing program fragments to
develop a working program.
46. What is the advantage of incremental model?
Incremental model is useful when staffing is unavailable.
Increments can be planned to manage technical risks.
47. Drawbacks of spiral model
If major risks are not discovered and managed problems will occur.
It demands a direct consideration of technical risks at all stages of project.
48. Identify in which phase of the software life cycle the following documents are
delivered.
a. Architectural design, b. Test plan, c. Cost estimate, d. Source code document.
 Architectural design: Design phase
 Test plan : Testing phase
 Cost estimate: Requirement analysis
 Source code: Implementation phase
49. Various phases of System engineering. process
 Requirement analysis
 System design
 Sub_ System development
 System Integration
 System deployment
 System evolution
 System decommissioning.
50. . Define System Engineering. Hierarchy
System Engg encompasses a collection of top-down and bottom up methods to navigate
the hierarchy.
The levels are
World view
Domain view
Element view
Detailed view
51. . Define a system and computer based system.
 Systemis an established way of doing something like method, procedure.
 Computer based system is a set of arrangement of elements that are organized to
accomplish some predefined goal by processing information system elements.
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 12
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
52. Define Business Process Engineering (BPE)
The goal of Business Process Engineering (BPE) is to define architectures that will enable a
business to use information effectively. Three different architectures are
Data architecture
Applications architecture
Technology architecture
53. Define Product engineering.
The goal of product engg is to translate the customer’s desire for a set of defined
functionalities into a working product. Four components are software , hardware ,data , people.
54. State the major difference between software engineering process and software
development process (NOV/DEC/2014)
 Software development and software engineering are interrelated terms, but they don’t
mean quite the same thing.
 A software engineer is engaged in software development; not all software developers,
however, are engineers.
 Software engineering means applying engineering principles to software creation. It
can seem odd to talk about engineering something that doesn’t have mass or take up
space, but software is embedded in things that do have mass.
 Software does everything from dispense our medication to control large equipment.
Many people also rely on software to perform job duties, whether they work in an
office or telecommute.. They work through the development process in a systematic
way; this is called the software development life cycle.
55. State the difference between process and product (MAY/JUNE/2014)
A software process as mentioned earlier, specifies a method of development software. A
software project, on the other hand is a development project in which a software process is
used. And software products are the outcomes of a software project.
PART B (16 marks)
1. Elaborate on business process engineering and product engineering (NOV/DEC/2010)\
OR
2. Business process engineering strives to define data and application architecture as well
as technology infrastructure. Describe what each of these terms mean and provide an
example (NOV/DEC/2012)
OR
3. Explain the concept of business process engineering (MAY/JUN/2012)
(MAY/JUN/2013) (NOV/DEC/2013) (NOV/DEC/2014) (MAY/JUNE/2014)
OR
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 13
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
4. Explain the concept of product engineering (APR/MAY/2011) (MAY/JUN/2012)
(MAY/JUN/2013) (NOV/DEC/2013) (NOV/DEC/2014) (MAY/JUNE/2014)
Business process engineering Hierarchy
 The goal of business process engineering (BPE) is to define architectures that will enable a
business to use information effectively.
 When taking a world view of a company’s information technology needs, there is little doubt
that system engineering is required. Not only the specification of the appropriate computing
architecture required, but the software architecture that populates the ―unique configuration
of heterogeneous computing resources‖ must be developed.
 Business process engineering is one approach for creating an overall plan for implementing
the computing architecture.
 Three different architectures must be analyzed and designed within the context of business
objectives and goals:
o data architecture
o applications architecture
o technology infrastructure
 The data architecture provides a framework for the information needs of a business or
business function. The individual building blocks of the architecture are the data objects that
are used by the business. A data object contains a set of attributes that define some aspect,
quality, characteristic, or descriptor of the data that are being described.
 The application architecture encompasses those elements of a system that transform objects
within the data architecture for some business purpose. In the context of this book, we
consider the application architecture to be the system of programs (software) that performs
this transformation. However, in a broader context, the application architecture might
incorporate the role of people (who are information transformers and users) and business
procedures that have not been automated.
 The technology infrastructure provides the foundation for the data and application
architectures. The infrastructure encompasses the hardware and software that are used to
support the application and data. This includes computers, operating systems, networks,
telecommunication links, storage technologies, and the architecture (e.g., client/server) that
has been designed to implement these technologies.
 The final BPE step—construction and integration focuses on implementation detail. The
architecture and infrastructure are implemented by constructing an appropriate database and
internal data structures, by building applications using software components, and by selecting
appropriate elements of a technology infrastructure to support the design created during BSD.
 Each of these system components must then be integrated to form a complete information
system or application.
 The integration activity also places the new information system into the business area
context, performing all user training and logistics support to achieve a smooth transition.
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 14
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
Product Engineering
 The goal of product engineering is to translate the customer‗s desire for a set of defined
capabilities into a working product. To achieve this goal, product engineering—like
business process engineering—must derive architecture and infrastructure.
 The architecture encompasses four distinct system components: software, hardware, data
(and databases), and people. A support infrastructure is established and includes the
technology required to tie the components together and the information (e.g.,
documents,CD-ROM, video) that is used to support the components.
 The world view is achieved through requirements engineering. The overall requirements
of the product are elicited from the customer. These requirements encompass information
and control needs, product function and behavior, overall product performance, design
and interfacing constraints, and other special needs.
 Once these requirements are known, the job of requirements engineering is to allocate
function and behavior to each of the four components noted earlier. Once allocation has
occurred, system component engineering commences.
 System component engineering is actually a set of concurrent activities that address each
of the system components separately: software engineering, hardware engineering,
human engineering, and database engineering.
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 15
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT



Each of these engineering disciplines takes a domain-specific view, but it is important to
note that the engineering disciplines must establish and maintain active communication
with one another. Part of the role of requirements engineering is to establish the
interfacing mechanisms that will enable this to happen.
The element view for product engineering is the engineering discipline itself applied to
the allocated component. For software engineering, this means analysis and design
modeling activities (covered in detail in later chapters) and construction and integration
activities that encompass code generation, testing, and support steps.
The analysis step models allocated requirements into representations of data, function,
and behavior. Design maps the analysis model into data, architectural, interface, and
software component-level designs.
5. Bring out clearly the salient features of waterfall model and spiral model. What are the
specific advantages and disadvantages of these two models (APR/MAY/2011)
OR
6. Explain the salient features of the “classical life cycle model” (NOV/DEC/2013)
( Answer waterfall model)
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 16
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
or
7. Describe the waterfall lifecycle model for software developer with a
sketch.”Management tends to like the waterfall model “. Justify (NOV/DEC/2010)
or
8. How do project risk factors affect the spiral model of software development
(APR/MAY/2010) ( answer – spiral model)
A Programming process model is an abstract representation to describe the process from a
particular perspective. There are numbers of general models for software processes, like:
Waterfall model, Evolutionary development, Formal systems development and Reuse based
Development, etc. This research will view the following five models
:
 Waterfall model.
 Iteration model.
 V-shaped model.
 Spiral model.
 Extreme model. These models are chosen because their features correspond to most
software development programs.
 The Waterfall Model or Classical life cycle or linear sequential; model
The waterfall model is the classical model of software engineering. This model is one of the
oldest models and is widely used in government projects and in many major companies. As this
model emphasizes planning in early stages, it ensures design flaws before they develop. In
addition, its intensive document and planning make it work well for projects in which quality
control is a major concern.
The pure waterfall lifecycle consists of several no overlapping stages, as shown in the following
figure. The model begins with establishing system requirements and software requirements and
continues with architectural design, detailed design, coding, testing, and maintenance.
The waterfall model serves as a baseline for many other lifecycle models.
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 17
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 18
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
The following list details the steps for using the waterfall model:
1. System requirements: Establishes the components for building the system, including
the hardware requirements, software tools, and other necessary components. Examples
include decisions on hardware, such as plug-in boards (number of channels, acquisition
speed, and so on), and decisions on external pieces of software, such as databases or
libraries.
2. Software requirements: Establishes the expectations for software functionality and
identifies which system requirements the software affects. Requirements analysis
includes determining interaction needed with other applications and databases,
performance requirements, user interface requirements, and so on.
3. Architectural design: Determines the software framework of a system to meet the
specific requirements. This design defines the major components and the interaction of
those components, but it does not define the structure of each component. The external
interfaces and tools used in the project can be determined by the designer.
4. Detailed design: Examines the software components defined in the architectural design
stage and produces a specification for how each component is implemented.
5. Coding: Implements the detailed design specification.
6. Testing: Determines whether the software meets the specified requirements and finds
any errors present in the code.
7. Maintenance: Addresses problems and enhancement requests after the software releases.
 In some organizations, a change control board maintains the quality of the product by
reviewing each change made in the maintenance stage. Consider applying the full
waterfall development cycle model when correcting problems or implementing these
enhancement requests.
 In each stage, documents that explain the objectives and describe the requirements for
that phase are created. At the end of each stage, a review to determine whether the project
can proceed to the next stage is held. Your prototyping can also be incorporated into any
stage from the architectural design and after.
 Many people believe that this model cannot be applied to all situations. For example,
with the pure waterfall model, the requirements must be stated before beginning the
design, and the complete design must be stated before
 starting coding. There is no overlap between stages. In real-world development, however,
one can discover issues during the design or coding stages that point out errors or gaps in
the requirements.
 The waterfall method does not prohibit returning to an earlier phase, for example,
returning from the design phase to the requirements phase. However, this involves costly
rework. Each completed phase requires formal review and extensive documentation
development. Thus, oversights made in the requirements phase are expensive to correct
later.
 Because the actual development comes late in the process, one does not see results for a
long time. This delay can be disconcerting to management and
 customers. Many people also think that the amount of documentation is excessive and
inflexible.
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 19
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
 Although the waterfall model has its weaknesses, it is instructive because it emphasizes
important stages of project development. Even if one does not apply this model, he must
consider each of these stages and its relationship to his own project [4].
Advantages :
 Easy to understand and implement.
 Widely used and known (in theory!).
 Reinforces good habits: define-before- design, design-before-code
 Identifies deliverables and milestones.
 Document driven, URD, SRD, … etc. Published documentation standards, e.g. PSS-05.
 Works well on mature products and weak teams.
Disadvantages :
 Idealized, doesn’t match reality well.
 Doesn’t reflect iterative nature of exploratory development.
 Unrealistic to expect accurate requirements so early in project
 Software is delivered late in project, delays discovery of serious errors
 Difficult to integrate risk management
 . Difficult and expensive to make changes to documents, ”swimming upstream”.
 Significant administrative overhead, costly for small teams and projects
Pure Waterfall
This is the classical system development model. It consists of discontinuous phases:
1. Concept.
2. Requirements.
3. Architectural design.
4. Detailed design.
5. Coding and development.
6. Testing and implementation.
Table 1: Strengths & Weaknesses of Pure Waterfall
Strengths
Weaknesses
Structure minimizes wasted effort, so it works Inflexible
well for technically weak or inexperienced
staff.
Minimizes planning overhead since it can be
Only the final phase produces a no
done up front.
documentation deliverable.
Backing up to address mistakes is difficult
.
Pure Waterfall Summary
The pure waterfall model performs well for products with clearly understood requirements or
when working with well understood technical tools, architectures and infrastructures. Its
weaknesses frequently make it inadvisable when rapid development is needed. In those cases,
modified models may be more effective.
Modified Waterfall
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 20
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
The modified waterfall uses the same phases as the pure waterfall, but is not based on a
discontinuous basis. This enables the phases to overlap when needed. The pure waterfall can also
split into subprojects at an appropriate phase (such as after the architectural design or detailed
design).
Table 2: Strengths & Weaknesses of Modified Waterfall
Strengths
Weaknesses
If there is personnel continuity between the
Activities performed in parallel are subject to
phases, documentation can be substantially
miscommunication and mistaken assumptions.
reduced.
More flexible than the pure waterfall model.
Milestones are more ambiguous than the pure
waterfall.
Implementation of easy areas does not need to Unforeseen interdependencies can create
wait for the hard ones.
problems
.
 Modified Waterfall Summary
 Risk reduction spirals can be added to the top of the waterfall to reduce risks prior to the
waterfall phases. The waterfall can be further modified using options such as prototyping,
JADs or CRC sessions or other methods of requirements gathering done in overlapping
phases
The Waterfall Model should use in projects with clearly and deeply understood of project
requirements, design, technical tools and infrastructures.
Spiral Model
 The spiral model, originally proposed by Boehm [BOE88], is an evolutionary software
process model that couples the iterative nature of prototyping with the controlled and
systematic aspects of the linear sequential model. It provides the potential for rapid
development of incremental versions of the software. Using the spiral model, software is
developed in a series of incremental releases. During early iterations, the incremental
release might be a paper model or prototype. During later iterations, increasingly more
complete versions of the engineered system are produced.
 A spiral model is divided into a number of framework activities, also called task regions.
Typically, there are between three and six task regions. Figure 2.8 depicts a spiral model
that contains six task regions:
 Customer communication—tasks required to establish effective communication
between developer and customer.
 Planning—tasks required to define resources, timelines, and other project related
information.
 Risk analysis—tasks required to assess both technical and management risks.
 Engineering—tasks required to build one or more representations of the application.
 Construction and release—tasks required to construct, test, install, and provide user
support (e.g., documentation and training).
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 21
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
Spiral model is an evolutionary version of incremental prototyping.
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 22
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
 Incremental development means that the project is not done by (possibly large) pieces,
but as a series of smaller developments and deliveries. Incremental models try to reduce
the risk of developing the wrong system by delivering useful parts of the system early
and getting customer feedback. System functionality and reliability requirements will
grow over the time, from an early version only for the development or for users, to
version released to final customers later.
 What about testing in spiral model? In spiral model testing must be adapted to such
development models, and continuous integration testing and regression testing are
necessary. The tests should be reusable test cases for every component and increment,
and it should be reused and updated for every additional increment. If this is not a case,
the software reliability tends to decrease over time instead of increasing.
Advantages
 Spiral Life Cycle Model is a very flexible model. Development phases can be determined
by the project manager, according to the complexity of the project.
 Estimates (i.e. budget, schedule, etc.) get more realistic as work progresses, because
important issues are discovered earlier.
 Good for large and mission-critical projects.
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 23
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
 Software is produced early in the software life cycle.
Disadvantages
 Doesn’t work well for smaller projects.
 Evaluating the risks involved in the project can shoot up the cost and it may
be higher than the cost for building the system.
 Spiral model is much customized for every project.
 Risk analysis requires highly specific expertise.
It serves as the best option for businesses with volatile business goals but where there is a
need for a prototype to handle the complexities in the business procedures.
9. In the software development models available, which of the model can be suggested to
achieve high speed development? Explain (NOV/DEC/2012)
The RAD Model
Rapid application development (RAD) is an incremental software development process
model that emphasizes an extremely short development cycle. The RAD model is a “highspeed” adaptation of the linear sequential model in which rapid development is achieved by
using component-based construction. If requirements are well understood and project scope is
constrained, the RAD process enables a development team to create a “fully functional system”
within very short time periods (e.g., 60 to 90 days
The RAD (Rapid Application Development) model is based on prototyping and iterative
development with no specific planning involved. The process of writing the software itself
involves the planning required for developing the product.
Rapid Application development focuses on gathering customer requirements through
workshops or focus groups, early testing of the prototypes by the customer using iterative
concept, reuse of the existing prototypes (components), continuous integration and rapid
delivery.
What is RAD?
Rapid application development (RAD) is a software development methodology that uses
minimal planning in favor of rapid prototyping. A prototype is a working model that is
functionally equivalent to a component of the product.
In RAD model the functional modules are developed in parallel as prototypes and are
integrated to make the complete product for faster product delivery.
Since there is no detailed preplanning, it makes it easier to incorporate the changes within
the development process. RAD projects follow iterative and incremental model and have small
teams comprising of developers, domain experts, customer representatives and other IT
resources working progressively on their component or prototype.
The most important aspect for this model to be successful is to make sure that the
prototypes developed are reusable.
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 24
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
RAD Model Design
RAD model distributes the analysis, design, build, and test phases into a series of short, iterative
development cycles. Following are the phases of RAD Model:





Business Modeling: The business model for the product under development is designed in terms
of flow of information and the distribution of information between various business channels.
A complete business analysis is performed to find the vital information for business, how it can
be obtained, how and when is the information processed and what are the factors driving
successful flow of information.
Data Modeling: The information gathered in the Business Modeling phase is reviewed and
analyzed to form sets of data objects vital for the business. The attributes of all data sets is
identified and defined. The relation between these data objects are established and defined in
detail in relevance to the business model.
Process Modeling: The data object sets defined in the Data Modeling phase are converted to
establish the business information flow needed to achieve specific business objectives as per the
business model. The process model for any changes or enhancements to the data object sets is
defined in this phase. Process descriptions for adding , deleting, retrieving or modifying a data
object are given.
Application Generation: The actual system is built and coding is done by using automation
tools to convert process and data models into actual prototypes.
Testing and Turnover:The overall testing time is reduced in RAD model as the prototypes are
independently tested during every iteration. However the data flow and the interfaces between all
the components need to be thoroughly tested with complete test coverage. Since most of the
programming components have already been tested, it reduces the risk of any major issues.
Following image illustrates the RAD Model:
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 25
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
Drawbacks of RAD Model
 For large but scalable projects, RAD requires sufficient human resources to create the
right number of RAD teams.
 RAD requires developers and customers who are committed to the rapid-fire activities
necessary to get a system complete in a much abbreviated time frame.
 If commitment is lacking from either constituency, RAD projects will fail.
 Not all types of applications are appropriate for RAD. If a system cannot be properly
modularized, building the components necessary for RAD will be problematic.
 If high performance is an issue and performance is to be achieved through tuning the
interfaces to system components, the RAD approach may not work.
 RAD is not appropriate when technical risks are high. This occurs when a new
application makes heavy use of new technology or when the new software requires a high
degree of interoperability with existing computer programs.
10. Describe the activities for a generic system modeling process. Illustrate with an example
(MAY/JUN/2013)
Five Activities of a Generic Process framework
• Communication: communicate with customer to understand objectives and gather
requirements
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 26
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Planning: creates a “map” defines the work by describing the tasks, risks and resources,
work products and work schedule.
Modeling: Create a “sketch”, what it looks like architecturally, how the constituent parts
fit together and other characteristics.
Construction: code generation and the testing.
Deployment: Delivered to the customer who evaluates the products and provides
feedback based on the evaluation.
These five framework activities can be used to all software development regardless of the
application domain, size of the project, complexity of the efforts etc, though the details
will be different in each case.
For many software projects, these framework activities are applied iteratively as a
project progresses. Each iteration produces a software increment that provides a subset of
overall software features and functionality.
Umbrella Activities
Complement the five process framework activities and help team manage and control
progress, quality, change, and risk.
Software project tracking and control: assess progress against the plan and take actions to
maintain the schedule.
Risk management: assesses risks that may affect the outcome and quality.
Software quality assurance: defines and conduct activities to ensure quality.
Technical reviews: assesses work products to uncover and remove errors before going to
the next activity.
Measurement: define and collects process, project, and product measures to ensure
stakeholder’s needs are met.
Software configuration management: manage the effects of change throughout the
software process.
Reusability management: defines criteria for work product reuse and establishes
mechanism to achieve reusable components.
Work product preparation and production: create work products such as models,
documents, logs, forms and lists.
George Polya outlines the essence of problem solving, suggests:
1.
Understand the problem (communication and analysis).
 Who has a stake in the solution to the problem? That is, who are the stakeholders?
 What are the unknowns? What data, functions, and features are required to
properly solve the problem?
 Can the problem be compartmentalized? Is it possible to represent smaller
problems that may be easier to understand?
 Can the problem be represented graphically? Can an analysis model be created?
2.
Plan a solution (modeling and software design).
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 27
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
 Have you seen similar problems before? Are there patterns that are recognizable
in a potential solution? Is there existing software that implements the data,
functions, and features that are required?
 Has a similar problem been solved? If so, are elements of the solution reusable?
 Can subproblems be defined? If so, are solutions readily apparent for the
subproblems?
 Can you represent a solution in a manner that leads to effective implementation?
Can a design model be created?
3.
Carry out the plan (code generation).
 Does the solutions conform to the plan? Is source code traceable to the design
model?
 Is each component part of the solution provably correct? Has the design and code
been reviewed, or better, have correctness proofs been applied to algorithm?
4.
Examine the result for accuracy (testing and quality assurance).
 Is it possible to test each component part of the solution? Has a reasonable
testing strategy been implemented?
 Does the solution produce results that conform to the data, functions, and features
that are required? Has the software been validated against all stakeholder
requirements?
Insulin pump control system
 A personal insulin pump
o An embedded system in an insulin pump used by diabetics to maintain blood
glucose control.
 Collects data from a blood sugar sensor and calculates the amount of insulin required to
be injected.
 Calculation based on the rate of change of blood sugar levels.
 Sends signals to a micro-pump to deliver the correct dose of insulin.
 Safety-critical system as low blood sugars can lead to brain malfunctioning, coma and
death; high-blood sugar levels have long-term consequences such as eye and kidney
damage
Hardware Architecture
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 28
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
Activity model of the insulin pump
Essential high-level requirements
•
•
•
•
The system shall be available to deliver insulin when required.
The system shall perform reliably and deliver the correct amount of insulin to counteract
the current level of blood sugar.
The system must therefore be designed and implemented to ensure that the system always
meets these requirements.
.
PART B (8 marks)
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 29
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
1. Discuss major areas of the application of the software (APR/MAY/2010)
Software Applications
1. Stand-alone applications These are application systems that run on a local computer,
such as a PC. They include all necessary functionality and do not need to be connected to
a network. Examples of such applications are office applications on a PC, CAD
programs, photo manipulation software, etc.
2. Interactive transaction-based applications These are applications that execute on
a remote computer and that are accessed by users from their own PCs or terminals.
Obviously, these include web applications such as e-commerce applications where you
can interact with a remote system to buy goods and services. This class of application
also includes business systems, where a business provides access to its systems through a
web browser or special-purpose client program and cloud-based services, such as mail
and photo sharing. Interactive applications often incorporate a large data store that is
accessed and updated in each transaction.
3. Embedded control systems These are software control systems that control and
manage hardware devices. Numerically, there are probably more embedded systems than
any other type of system. Examples of embedded systems include the software in a
mobile (cell) phone, software that controls anti-lock braking in a car, and software in a
microwave oven to control the cooking process.
4. Batch processing systems These are business systems that are designed to process
data in large batches. They process large numbers of individual inputs to create
corresponding outputs. Examples of batch systems include periodic billing systems, such
as phone billing systems, and salary payment systems.
5. Entertainment systems These are systems that are primarily for personal use and
which are intended to entertain the user. Most of these systems are games of one kind or
another. The quality of the user interaction offered is the most important distinguishing
characteristic of entertainment systems.
6. Systems for modeling and simulation These are systems that are developed by
scientists and engineers to model physical processes or situations, which include many,
separate, interacting objects. These are often computationally intensive and require highperformance parallel systems for execution.
7. Data collection systems These are systems that collect data from their environment
using a set of sensors and send that data to other systems for processing. The software has
to interact with sensors and often is installed in a hostile environment such as inside an
engine or in a remote location.
8. Systems of systems These are systems that are composed of a number of other
software systems. Some of these may be generic software products, such as a spreadsheet
program. Other systems in the assembly may be specially written for that environment.
9. Open world computing—pervasive, ubiquitous, distributed computing due to wireless
networking. How to allow mobile devices, personal computer, enterprise system to
communicate across vast network.
10. Netsourcing—the Web as a computing engine. How to architect simple and sophisticated
applications to target end-users worldwide.
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 30
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
11. Open source—”free” source code open to the computing community
a. Data mining
b. Grid computing
c. Cognitive machines
d. Software for nanotechnologies
2. Describe the role of management in software development with the help of examples
(APR/MAY/2010)
3. Explain the following (APR/MAY/2011) (MAY/JUN/2012) (MAY/JUN/2013)
(NOV/DEC/2013)
a. System engineering
OR
4. What is the system modeling? State and explain the restraining fact to construct a
system model (NOV/DEC/2010) ( Answer – only system modeling)
OR
5. Draw a system engineering hierarchy diagram and explain the concept
(NOV/DEC/2011) (NOV/DEC/2013) (NOV/DEC/2014) (MAY/JUNE/2014)
 Software engineering occurs as a consequence of a process called system engineering.
 Instead of concentrating solely on software, system engineering focuses on a variety of elements,
analyzing, designing, and organizing those elements into a system that can be a product, a
service, or a technology for the transformation of information or control. The system engineering
process usually begins with a ―world view. That is, the entire business or product domain is
examined to ensure that the proper business or technology context can be established.
 The world view is refined to focus more fully on specific domain of interest. Within a specific
domain, the need for targeted system elements (e.g., data, software, hardware, people) is
analyzed. Finally, the analysis, design, and construction of a targeted system element is initiated.
At the top of the hierarchy, a very broad context is established and, at the bottom, detailed
technical activities, performed by the relevant engineering discipline (e.g., hardware or software
engineering), is conducted. Stated in a slightly more formal manner, the world view (WV) is
composed of a set of domains (Di), which can each be a system or system of systems in its own
right.
WV = {D1, D2, D3, . . . , Dn}
 Each domain is composed of specific elements (Ej) each of which serves some role in
accomplishing the objective and goals of the domain or component:
Di = {E1, E2, E3, . . . , Em}
 Finally, each element is implemented by specifying the technical components (Ck) that achieve
the necessary function for an element:
Ej = {C1, C2, C3, . . . , Ck}
 It is important to note that the system engineer narrows the focus of work as he or she moves
downward in the hierarchy just described. However, the world view portrays a clear
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 31
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
definition of overall functionality that will enable the engineer to understand the domain, and
ultimately the system or product, in the proper context
System Modeling
System engineering is a modeling process. Whether the focus is on the world view or the
detailed view, the engineer creates models that
• Define the processes that serve the needs of the view under consideration.
• Represent the behavior of the processes and the assumptions on which the behavior is
based.
• Explicitly define both exogenous and endogenous input3 to the model.
• Represent all linkages (including output) that will enable the engineer to better
understand the view.
To construct a system model, the engineer should consider a number of restraining factors:
• Assumptions that reduce the number of possible permutations and variations, thus
enabling a model to reflect the problem in a reasonable manner. As an example, consider
a three-dimensional rendering product used by the entertainment industry to create
realistic animation. One domain of the product enables the representation of 3D human
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 32
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
•
•
•
•
forms. Input to this domain encompasses the ability to specify movement from a live
human actor, from video, or by the creation of graphical models. The system engineer
makes certain assumptions about the range of allowable human movement (e.g., legs
cannot be wrapped around the torso) so that the range of inputs and processing can be
limited.
Simplifications that enable the model to be created in a timely manner. To illustrate,
consider an office products company that sells and services a broad range of copiers,
faxes, and related equipment. The system engineer is modeling the needs of the service
organization and is working to understand the flow of information that spawns a service
order. Although a service order can be derived from many origins, the engineer
categorizes only two sources: internal demand and external request. This enables a
simplified partitioning of input that is required to generate the service order.
Limitations that help to bound the system. For example, an aircraft avionics system is
being modeled for a next generation aircraft. Since the aircraft will be a two-engine
design, the monitoring domain for propulsion will be modeled to accommodate a
maximum of two engines and associated redundant systems.
Constraints that will guide the manner in which the model is created and the approach
taken when the model is implemented. For example, the technology infrastructure for the
three-dimensional rendering system described previously is a single G4-based processor.
The computational complexity of problems must be constrained to fit within the
processing bounds imposed by the processor.
Preferences that indicate the preferred architecture for all data, functions, and technology.
The preferred solution sometimes comes into conflict with other restraining factors. Yet,
customer satisfaction is often predicated on thedegree to which the preferred approach is
realized.
.
System Simulation
•
•
•
•
In fact, for at least one class of system—the reactive system—we continue to do this
today.
Many computer-based systems interact with the real world in a reactive fashion. That is,
real-world events are monitored by the hardware and software that form the computerbased system, and based on these events; the system imposes control on the machines,
processes, and even people who cause the events to occur. Real-time and embedded
systems often fall into the reactive systems category.
Unfortunately, the developers of reactive systems sometimes struggle to make them
perform properly. Until recently, it has been difficult to predict the performance,
efficiency, and behavior of such systems prior to building them. In a very real sense, the
construction of many real-time systems was an adventure in "flying."
Many systems in the reactive category control machines and/or processes (e.g.,
commercial aircraft or petroleum refineries) that must operate with an extremely high
degree of reliability. If the system fails, significant economic or human loss could occur.
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 33
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
•
Today, software tools for system modeling and simulation are being used to help to
eliminate surprises when reactive, computer-based systems are built. These tools are
applied during the system engineering process, while the role of hardware and software,
databases and people is being specified. Modeling and simulation tools enable a system
engineer to "test drive" a specification of the system.
6. Describe the process model which defines a network of activities (NOV/DEC/2011)
The Concurrent Development Model

The concurrent development model, sometimes called concurrent engineering, The
concurrent process model can be represented schematically as a series of major technical
activities, tasks, and their associated states. For example, the engineering activity defined for
the spiral model is accomplished by invoking the following tasks: prototyping and/or analysis
modeling, requirements specification, and design.
 Figure 2.10 provides a schematic representation of one activity with the concurrent process
model. The activity—analysis—may be in any one of the states10 noted at any given time.
Similarly, other activities (e.g., design or customer communication) can be represented in an
analogous manner.
 All activities exist concurrently but reside in different states. For example, early in a project
the customer communication activity (not shown in the figure) has completed its first
iteration and exists in the awaiting changes state.
 The analysis activity (which existed in the none state while initial customer communication
was completed) now makes a transition into the under development state. If, however, the
customer indicates that changes in requirements must be made, the analysis activity moves
from the under development state into the awaiting changes state.
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 34
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
 The concurrent process model defines a series of events that will trigger transitions from state
to state for each of the software engineering activities. For example,
 during early stages of design, an inconsistency in the analysis model is uncovered.
 This generates the event analysis model correction which will trigger the analysis activity
from the done state into the awaiting changes state.
 The concurrent process model is often used as the paradigm for the development of
client/server applications. A client/server system is composed of a set of functional
components.
 When applied to client/server, the concurrent process model defines activities in two
dimensions
 a system dimension
o System level issues are addressed using three activities: design, assembly, and use.
 a component dimension
o The component dimension is addressed with two activities: design and realization.
 Concurrency is achieved in two ways:
o system and component activities occur simultaneously and can be modeled using the
state-oriented approach described previously;
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 35
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
o a typical client/server application is implemented with many components, each of
which can be designed and realized concurrently.
 In reality, the concurrent process model is applicable to all types of software development
and provides an accurate picture of the current state of a project. Rather than confining
software engineering activities to a sequence of events, it defines a network of activities.
Each activity on the network exists simultaneously with other activities.
 Events generated within a given activity or at some other place in the activity network trigger
transitions among the states of an activity.
7. Explain the process model that combines the elements of waterfall and iterative
fashion (NOV/DEC/2011)
The Incremental Model
The incremental model combines elements of the linear sequential model or waterfall
model (applied repetitively) with the iterative philosophy of prototyping.
Referring to Figure 2.7, the incremental model applies linear sequences in a staggered fashion as
calendar time progresses. Each linear sequence produces a deliverable “increment” of the
software
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 incorporate the
prototyping paradigm.
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 review). As
a result of use and/or evaluation, a plan is developed for the next increment. The plan addresses
the modification of the core product to better meet the needs of the customer and the delivery of
additional features and functionality. This process is repeated following the delivery of each
increment, until the complete product is produced.
The incremental process model, like prototyping and other evolutionary approaches, is iterative
in nature. But unlike prototyping, the incremental model focuses on the delivery of an
operational product with each increment. Early increments are stripped down versions of the
final product, but they do provide capability that serves the user and also provide a platform for
evaluation by the user.
Incremental development is particularly useful when staffing is unavailable for a complete
implementation by the business deadline that has been established for the project. Early
increments can be implemented with fewer people. If the core product is well received, then
additional staff (if required) can be added to implement the next increment. In addition,
increments can be planned to manage technical risks. For example, a major system might require
the availability of new hardware that is under development and whose delivery date is uncertain.
It might be possible to plan early increments in a way that avoids the use of this hardware,
thereby enabling partial functionality to be delivered to end-users without inordinate delay.
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 36
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
8. Suppose you have to develop software for a client with minimum risk involved in
development. But the client is not in a position to define the detailed input and output
requirements. In this situation which software process model would you like to
choose? Justify your answer (MAY/JUN/2012)
OR
9. State as to why the first system is always a throw away system. Explain the concept
with advantages and disadvantages (NOV/DEC/2011)
THE PROTOTYPING MODEL
 Often, a customer defines a set of general objectives for software but does not
identify detailed input, processing, or output requirements. 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.
 The prototyping paradigm (Figure 2.5) begins with requirements gathering. Developer
and customer meet and define the overall objectives for the software, identify whatever
requirements are known, and outline areas where further definition is mandatory. A
"quick design" then occurs.
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 37
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
 The quick design focuses on a representation of those aspects of the software that
will be visible to the customer/user (e.g., input approaches and output formats). The
quick design leads to the construction of a prototype. The prototype is evaluated by the
customer/user and used to refine requirements for the software to be developed. Iteration
occurs as the prototype is tuned to satisfy the needs of the customer, while at the same
time enabling the developer to better understand what needs to be done.
 Ideally, the prototype serves as a mechanism for identifying software requirements. If a
working prototype is built, the developer attempts to use existing program fragments or
applies tools (e.g., report generators, window managers) that enable working programs to
be generated quickly.
 The prototype can serve as "the first system." The one that Brooks recommends we
throw away. But this may be an idealized view. It is true that both customers and
developers like the prototyping paradigm. Users get a feel for the actual system and
developers get to build something immediately.
, prototyping can also be problematic for the following reasons:
1. The customer sees what appears to be a working version of the software, unaware that the
prototype is held together “with chewing gum and baling wire,” unaware that in the rush to get it
working no one has considered overall software quality or long-term maintainability. When
informed that the product must be rebuilt so that high levels of quality can be maintained, the
customer cries foul and demands that "a few fixes" be applied to make the prototype a working
product. Too often, software development management relents.
2. The developer often makes implementation compromises in order to get a prototype working
quickly. An inappropriate operating system or programming language may be used simply
because it is available and known; an inefficient algorithm may be implemented simply to
demonstrate capability.
Although problems can occur, prototyping can be an effective paradigm for software
engineering. The key is to define the rules of the game at the beginning; that is, the customer and
developer must both agree that the prototype is built to serve as a mechanism for defining
requirements. It is then discarded (at least in part) and the actual software is engineered with an
eye toward quality and maintainability.
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 38
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT

The benefits of developing a prototype early in the software process are :






PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Misunderstandings between software developers and users may be
identified as the system functions are demonstrated.
Missing user services may be detected.
Difficult-to-use or confusing user services may be identified and refined.
Software development staff may find incomplete and/or inconsistent
requirements as the prototype is developed.
A working, albeit limited, system is available quickly to demonstrate the
feasibility and usefulness of the application to management.
The prototype serves as a basis for writing the specification for a
production quality system.
Page 39
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT

Software prototypes also have other uses:
 User training
 System testing
 The final stage of the process is prototype evaluation.
 There are non-technical managerial problems which may make it difficult to use
prototyping in some organizations.
Prototyping in the software process
 One way of tackling this difficulty is to use an evolutionary approach to systems
development.
 Alternatively, a deliberate decision might be made to build a 'throw-away' prototype to
help requirements analysis and validation.
 There is an important difference between the objectives of evolutionary and throwaway programming:
o The objective of evolutionary prototyping is to deliver a working system to endusers.
o The objective of throw-away prototyping is to validate or derive the system
requirements.
Evolutionary prototyping
o There are three main problems with evolutionary prototyping which are
particularly important when large,long-lifetime systems are to be developed:
o Difficulties do not mean that evolutionary prototyping should be rejected.
 Throw-away prototyping
o
This approach extends the requirements analysis process with the intention of
reducing overall lige cycle costs.
o Customers and end-users should resist the temptation to turn the throw-away
prototyping into a delivered system that is put into use.
Incremental development



This incremental development model involves developing the requirements and
delivering the system in an incremental fashion.
Incremental development is more manageable than evolutionary prototyping as the
normal software process standards are followed.
A problem with incremental development is that the system architecture has to be
established before the requirements are complete.

Prototyping techniques

There are a number of techniques which have been used for system prototyping.
These include:
o Executable specification languages,
o very high level language,
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 40
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
o application generators and fourth-generation languages,
o Composition of reusable components.
Executable specification languages
o There are practical difficulties in applying this approach.
 Very high level languages
o Very high level languages are programming languages which include powerful
data management facilities.
o Very high level dynamic languages are not normally used for large system
development because they need a large run-time support system.
 Fourth-generation languages
o Fourth-generation languages are successful because there is a great deal of
commonality across data processing applications.
o There is no standardization or uniformity across fourth-generation languages.
Composition of reusable components
o Prototyping with reusable components involves developing a system
specification by taking account of what reusable components are available.
o Prototyping using reusable components is often combined with other approaches
using very high level or fourth-generation languages.
User interface prototyping
 Interface generation systems may be based around user interface management systems
which provide basic user interface functionality such as menu selection, object display
and so on.
 From a software engineering point of view, it is important to realize that user interface
prototyping is an essential part of the process.
10. Differentiate the features of various software lifecycle models highlighting their
advantages and disadvantages (MAY/JUN/2012) (NOV/DEC/2014)
(MAY/JUNE/2014)
SOFTWARE DEVELOPMENT MODELS
A) Original Waterfall Model
The Waterfall model is a conventional, linear,sequentional or traditional waterfall software life
cycle model. It is a sequential development approach, in which development is seen as flowing
steadily downwards through the phases of requirements analysis, design, implementation,
testing (validation), integration, and maintenance.
1) Basic Principles
 Project is divided into sequential phases, with some overlap and splash back acceptable
between phases.
 Emphasis is on planning, time schedules, target dates, budgets and implementation of an
entire system at one time.
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 41
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT

Tight control is maintained over the life of the project via extensive written
documentation, formal reviews, and approval/signoff by the user and information
technology management occurring at the end of most phases before beginning the next
phase.
2) Advantage of original water model:
 Each stage has well defined deliverable or milestone.
 It is simple to use and understand
 It acts as template into which methods for analysis, design, code test and maintenance
can be placed.
3) Disadvantage of original water model:
 The biggest disadvantage of the waterfall mode is one of its greatest advantages. You
cannot go back a step; if the design phase has gone wrong, things can get very
complicated in the implementation phase.
 Often, the client is not very clear of what he exactly wants from the software. Any
changes that he mentions in between may cause a lot of confusion.
 Small changes or errors that arise in the completed software may cause a lot of problems.
 Another major disadvantage of the waterfall model is that, until the final stage of the
development cycle is
Complete, a working model of the software does not lie in the hands of the client.
B) Iterative Waterfall Model
1) Basic Principles
 The problems with the Waterfall Model created a demand for a new method of
developing systems which could provide faster results, require less up-front information
and offer greater flexibility.
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 42
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT


Iterative model, the project is divided into small parts. This allows the development team
to demonstrate results earlier on in the process and obtain valuable feedback from
system users
each iteration is actually a mini-Waterfall process with the feedback from one phase
providing vital Information for the design of the next phase.
2) Advantages It is much better model of the software process.
 It allows feedback to proceeding stages.
 It can be used for project wherein the requirements are not well understood.
3) Disadvantages It is not easy to manage this model.
 No clear milestones in the development process.
 No stage is really finished.
C) Prototyping Model
Software prototyping is the development approach of activities during software development,
the creation of prototypes, i.e., incomplete versions of the software program being developed.
1) Basic Principles
 Not a standalone, complete development methodology, but rather an approach to
handling selected parts of a larger, more traditional development methodology.
 Attempts to reduce inherent project risk by breaking a project into smaller segments and
providing more ease-of-change during the development process.
 User is involved throughout the development process, which increases the likelihood of
user acceptance of the final implementation.
 Small-scale mock-ups of the system are developed following an iterative modification
process until the Prototype evolves to meet the users requirement.
 While most prototypes are developed with the expectation that they will be discarded, it
is possible in some cases to evolve from prototype to working system.
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 43
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT

A basic understanding of the fundamental business problem is necessary to avoid solving
the wrong problem.

2) Advantages Early visibility of the prototype gives users an idea of what the final system looks like
 Encourages active participation among users and producer.
 Enables a higher output for user.
 Cost effective (Development costs reduced)
 Increases system development speed
 Assists to identify any problems with the efficacy of earlier design, requirements analysis
and coding activities.
3) Disadvantages Possibility of causing systems to be left unfinished.
 Possibility of implementing systems before they are ready.
 Producer might produce a system inadequate for overall organization needs.
 Often lack flexibility.
 Not suitable for large applications.
 Project management difficulties.
D) Spiral Model
The spiral model is a software development process combining elements of both design and
prototyping-in-stages, in an effort to combine advantages of top-down and bottom up concepts. It
is a meta-model, a model that can be used by other models.
1) Basic Principles
 Focus is on risk assessment and on minimizing project risk by breaking a project into
smaller segments and providing more ease-of-change during the development process, as
well as providing the opportunity to evaluate risks and weigh consideration of project
continuation throughout the life cycle.
 Each cycle involves a progression through the same sequence of steps, for each part of
the product and for each of its levels of elaboration, from an overall concept-of-operation
document down to the coding of each individual program.
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 44
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT

Each trip around the spiral traverses four basic quadrants: (1) determine objectives,
alternatives, and constraints of the iteration; (2) evaluate alternatives; Identify and resolve
risks; (3) develop and verify deliverables from the iteration; and (4) plan the next
iteration.
 Begin each cycle with an identification of stakeholders and their win conditions, and end
each cycle with review and commitment.
 Every time a new prototype is obtained ,it is revaluated again and again by the customer
.so more customer involvement is there.
 Better productivity through reuse capabilities.
 Proper control over cost ,time and manpower requirement for a project work.
 Errors are eliminated in early phases of project development only.
3) Disadvantages This model requires risk identification, its projection, risk assessment and risk
management which is not an easy task.
 Cost and time estimations are also not very easy.
 This model is not suitable for smaller project as then the cost of risk analysis is greater
than cost of the entire project.
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 45
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
11. Select any large system or product of your choice. State the assumptions,
simplifications, limitations, constraints and preferences that would have to be made to
build a realizable system model (NOV/DEC/2012)
Software Requirement Specification Hospital Management System
1.1 - Purpose
• The Software is for the automation of Hospital Management.
• It maintains two levels of users:– Administrator Level
– User Level
• The Software includes:PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 46
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
– Maintaining Patient details.
– Providing Prescription, Precautions and Diet advice.
– Providing and maintaining all kinds of tests for a patient.
– Billing and Report generation.
1.2 - Scope
• It can be used in any Hospital, Clinic, Dispensary or Pathology labs for maintaining
patient details and their test results.
1.3 - Technologies to be used
• This project will be a desktop application to be developed in VB 6.0 having Ms Access as
backend.
• Database Design (Ms Access)
• Form Design (VB 6.0)
• Coding (VB 6.0)
• Testing (VB 6.0)
• Reporting Tool (Data Report)
1.4 - Overview
• Project is related to Hospital Management System.
• The project maintains two levels of users:• Administrator Level-Doctor
• User Level-Data Entry Operator
• Main facilities available in this project are:• Maintaining records of indoor/outdoor patients.
• Maintaining patients diagnosis details, advised tests to be done.
• Providing different test facilities to a doctor for diagnosis of patients.
• X-Ray
• Urine Test
• Stool Test
• Sonography Test
• Gastroscopy Test
• Colonoscopy Test
• Blood Test
• Biochemistry Test
• Maintaining patient’s injection entry records.
• Maintaining patient’s prescription, medicine and diet advice details.
• Providing billing details for indoor/outdoor patients.
• Maintaining backup of data as per user requirements (between mentioned dates).
• If user forgets his/her password then it can be retrieved by hint question.
• In this project collection of data is from different pathology labs.
• Results of tests, prescription, precautions and diet advice will be automatically updated
in the database.
• Related test reports, patient details report, prescription and billing reports can be
generated as per user requirements.
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 47
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
•
•
User or Administrator can search a patient’s record by his/her name or their registration
date.
Patient’s diet advice can be provided in Hindi.
12. Elaborate on the six elements of computer based systems (MAY/JUN/2013)
A system can be defined as a purposeful collection of inter-related components working
together to achieve some common objective. The system components are dependent on other
system components.
The computer based system can be defined as “a set or an arrangement of elements that are
organized to accomplish some predefined goal by processing information”.
Various elements of computer based system are
 Software - Computer software is a collection of computer programs, data structures and
related documentation that builds the logical method, procedures or control that is
required.
 Hardware - Hardware is a collection of electronic devices that provide computing
capability, interconnectivity devices for communicating with external world connectivity.
Examples of such
 interconnecting components are network switches, telecommunication devices
 People - Users and operators of hardware and software.
 Database - Database is a large and organized collection data that can be accessed by
software
 Documentation - Supporting descriptive information that represents the use and
operation of the system. The documentation can be in the form of hard copy manuals,
online help files or web sites.
 Procedures - A series of steps that define the specific use of each system element.
 The elements combine together to transform the information. Complex systems are
actually a hierarchy of macro-elements that are themselves systems. The role of system
engineer is to define the elements for a specific computer based system by considering
the context of the system.
For example A factory automation system is collection of various systems that themselves
are the combination of various elements. Various Macro-elements such as Numerical control
machine, Robot, Data entry devices form the lowest level of the system. These macro-elements
are basically formed by combining various elements such as hardware, software, procedures, and
databases. These lowest level elements together form manufacturing cell. One or more such cells
form the manufacturing system. Thus the manufacturing system is the next level in the hierarchy.
Along with manufacturing system, inventory control system, database management system build
the factory automation system
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 48
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
13. What are different approaches to the sizing problem (MAY/JUN/2012)
 Sizing represents the project planner’s first major challenge. In the context of project
planning, size refers to a quantifiable outcome of the software project. If a direct
approach is taken, size can be measured in LOC. If an indirect approach is chosen, size is
represented as FP.
 Putnam and Myers suggest four different approaches to the sizing problem:
 “Fuzzy logic” sizing. This approach uses the approximate reasoning techniques that are
the cornerstone of fuzzy logic. To apply this approach, the planner must identify the type
of application, establish its magnitude on a qualitative scale, and then refine the
magnitude within the original range. Although personal experience can be used, the
planner should also have access to a historical database of projects8 so that estimates can
be compared to actual experience.
 Function point sizing. The planner develops estimates of the information domain
characteristics
 Standard component sizing. Software is composed of a number of different “standard
components” that are generic to a particular application area. For example, the standard
components for an information system are subsystems, modules, screens, reports,
interactive programs, batch programs, files, LOC, and object-level instructions. The
project planner estimates the number of occurrences of each standard component and
then uses historical project data to determine the delivered size per standard component.
To illustrate, consider an information systems application. This enables the planner to
estimate that 17,000 LOC will be required for the reports component. Similar estimates
and computation are made for other standard components, and a combined size value
(adjusted statistically) results.
 Change sizing. This approach is used when a project encompasses the use of existing
software that must be modified in some way as part of a project. The planner estimates
the number and type (e.g., reuse, adding code, changing code, deleting code) of
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 49
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
modifications that must be accomplished. Using an “effort ratio” [PUT92] for each type
of change, the size of the change may be estimated
14. .Explain in detail about life cycle process?
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 50
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
15. Explain Win Win Spiral Model.
The spiral model suggests a framework activity that addresses customer communication. The
objective of this activity is to elicit project requirements from the customer. In an ideal context,
the developer simply asks the customer what is required and the customer provides sufficient
detail to proceed. Unfortunately, this rarely happens. In reality, the customer and the developer
enter into a process of negotiation, where the customer may be asked to balance functionality,
performance, and other product or system characteristics against cost and time to market.
The best negotiations strive for a “win-win” result.7 that is, the customer wins by getting
the system or product that satisfies the majority of the customer’s needs and the developer
wins by working to realistic and achievable budgets and deadlines
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 51
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
Boehm’s WINWIN spiral model [BOE98] defines a set of negotiation activities at the beginning
of each pass around the spiral. Rather than a single customer communication activity, the
following activities are defined:
1. Identification of the system or subsystem’s key “stakeholders.”8
2. Determination of the stakeholders’ “win conditions.”
3. Negotiation of the stakeholders’ win conditions to reconcile them into a set of win-win
conditions for all concerned (including the software project team).




The WINWIN spiral model is illustrated in Figure 2.9. In addition to the emphasis placed
on early negotiation, the WINWIN spiral model introduces three process milestones,
called anchor points [BOE96], that help establish the completion of one cycle around the
spiral and provide decision milestones before the software project proceeds.
In essence, the anchor points represent three different views of progress as the project
traverses the spiral. The first anchor point, life cycle objectives (LCO), defines a set of
objectives for each major software engineering activity. For example, as part of LCO, a
set of objectives establishes the definition of top-level system/product requirements.
The second anchor point, life cycle architecture (LCA), establishes objectives that must
be met as the system and software architecture is defined. For example, as part of LCA,
the software project team must demonstrate that it has evaluated the applicability of offthe-shelf and reusable software components and considered their impact on architectural
decisions.
Initial operational capability (IOC) is the third anchor point and represents a set of
objectives associated with the preparation of the software for installation/distribution, site
preparation prior to installation, and assistance required by all parties that will use or
support the software.
16. What are the two products used in software engineering
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 52
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
Software engineers are concerned with developing software products (i.e., software
which can be sold to a customer). There are two kinds of software products:
1. Generic products
These are stand-alone systems that are produced by a development organization
and sold on the open market to any customer who is able to buy them. Examples of
this type of product include software for PCs such as databases, word processors,
drawing packages, and project-management tools. It also includes so-called vertical
applications designed for some specific purpose such as library information systems,
accounting systems, or systems for maintaining dental records.
2. Customized (or bespoke) products
Software that is commissioned by a specific customer to meet their own needs.
A software contractor develops the software especially for that customer. Examples of
this type of software include control systems for electronic devices, systems written to
support a particular business process, and air traffic control systems
17. Explain software engineering in detail
Software Engineering – Definition
The seminal definition:
[Software engineering is] the establishment and use of sound engineering principles in order to
obtain economically software that is reliable and works efficiently on real machines.
The IEEE definition:
Software Engineering: (1) The application of a systematic, disciplined, quantifiable approach to
the development, operation, and maintenance of software; that is, the application of engineering
to software. (2) The study of approaches as in (1).
Software Engineering – A Layered Technology
 Any engineering approach must rest on organizational commitment to quality which
fosters a continuous process improvement culture.
 Process layer as the foundation defines a framework with activities for effective delivery
of software engineering technology. Establish the context where products (model, data,
report, and forms) are produced, milestone is established, quality is ensured and change is
managed.
 Method provides technical how-to be for building software. It encompasses many tasks
including communication, requirement analysis, design modeling, program construction,
testing and support.
 Tools provide automated or semi-automated support for the process and methods.
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 53
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
A Generic phases of software Engineering
The work associated with software engineering can be categorized into three generic
phases, regardless of application area, project size, or complexity.
1. The definition phase focuses on what.
The software engineer attempts to identify what information is to be processed,
what function and performance are desired, what system behavior can be expected, what
interfaces are to be established, what design constraints exist, and what validation criteria
are required to define a successful system. The key requirements of the system and the
software are identified. Although the methods applied during the definition phase will
vary depending on the software engineering paradigm (or combination of paradigms) that
is applied, three major tasks will occur in some form: system or information engineering,
software project planning, and requirements analysis .
2. The development phase focuses on how. That is, during development a software
engineer attempts to define how data are to be structured, how function is to be
implemented within a software architecture, how procedural details are to be
implemented, how interfaces are to be characterized, how the design will be translated
into a programming language (or nonprocedural language), and how testing will be
performed. The methods applied during the development phase will vary, but three
specific technical tasks should always occur: software design , code generation, and
software testing
3. The support phase focuses on change associated with error correction, adaptations
required as the software's environment evolves, and changes due to enhancements
brought about by changing customer requirements. The support phase reapplies the steps
of the definition and development phases but does so in the context of existing software.
Four types of change are encountered during the support phase:
a) Correction. Even with the best quality assurance activities, it is likely that the customer
will uncover defects in the software. Corrective maintenance changes the software to
correct defects.
b) Adaptation. Over time, the original environment (e.g., CPU, operating system, business
rules, external product characteristics) for which the software was developed is likely to
change. Adaptive maintenance results in modification to the software to accommodate
changes to its external environment.
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 54
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
c) Enhancement. As software is used, the customer/user will recognize additional
functions that will provide benefit. Perfective maintenance extends the software beyond
its original functional requirements.
d) Prevention. Computer software deteriorates due to change, and because of this,
preventive maintenance, often called software reengineering, must be conducted to
enable the software to serve the needs of its end users. In essence, preventive
maintenance makes changes to computer programs so that they can be more easily
corrected, adapted, and enhanced
18. Explain the software project management in detail
Effective software project management focuses on these items (in this order)
a. The people
(1) Deals with the cultivation of motivated, highly skilled people
(2) Consists of the stakeholders, the team leaders, and the software team
b. The product
(1) Product objectives and scope should be established before a project can be
planned
c. The process
(1) The software process provides the framework from which a comprehensive
plan for software development can be established
d. The project
(1) Planning and controlling a software project is done for one primary
reason…it is the only known way to manage complexity
(2) In a 1998 survey, 26% of software projects failed outright, 46% experienced
cost and schedule overruns
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 55
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
The People: The Stakeholders
• Five categories of stakeholders
– Senior managers – define business issues that often have significant influence on
the project
– Project (technical) managers – plan, motivate, organize, and control the
practitioners who do the work
– Practitioners – deliver the technical skills that are necessary to engineer a
product or application
– Customers – specify the requirements for the software to be engineered and other
stakeholders who have a peripheral interest in the outcome
– End users – interact with the software once it is released for production use
The People: Team Leaders
• Competent practitioners often fail to make good team leaders; they just don’t have the
right people skills
• Qualities to look for in a team leader
– Motivation – the ability to encourage technical people to produce to their best
ability
– Organization – the ability to mold existing processes (or invent new ones) that
will enable the initial concept to be translated into a final product
– Ideas or innovation – the ability to encourage people to create and feel creative
even when they must work within bounds established for a particular software
product or application
• Team leaders should use a problem-solving management style
– Concentrate on understanding the problem to be solved
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 56
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
–
–
Manage the flow of ideas
Let everyone on the team know, by words and actions, that quality counts and that
it will not be compromised
• Another set of useful leadership traits
– Problem solving – diagnose, structure a solution, apply lessons learned, remain
flexible
– Managerial identity – take charge of the project, have confidence to assume
control, have assurance to allow good people to do their jobs
– Achievement – reward initiative, demonstrate that controlled risk taking will not
be punished
– Influence and team building – be able to “read” people, understand verbal and
nonverbal signals, be able to react to signals, remain under control in high-stress
situations
The People: The Software Team
• Seven project factors to consider when structuring a software development team
– The difficulty of the problem to be solved
– The size of the resultant program(s) in source lines of code
– The time that the team will stay together
– The degree to which the problem can be modularized
– The required quality and reliability of the system to be built
– The rigidity of the delivery date
– The degree of sociability (communication) required for the project
• Four organizational paradigms for software development teams
– Closed paradigm – traditional hierarchy of authority; works well when
producing software similar to past efforts; members are less likely to be
innovative
– Random paradigm – depends on individual initiative of team members; works
well for projects requiring innovation or technological breakthrough; members
may struggle when orderly performance is required
– Open paradigm – hybrid of the closed and random paradigm; works well for
solving complex problems; requires collaboration, communication, and consensus
among members
– Synchronous paradigm – organizes team members based on the natural pieces
of the problem; members have little communication outside of their subgroups
• Five factors that cause team toxity (i.e., a toxic team environment)
– A frenzied work atmosphere
– High frustration that causes friction among team members
– A fragmented or poorly coordinated software process
– An unclear definition of roles on the software team
– Continuous and repeated exposure to failure
• How to avoid these problems
– Give the team access to all information required to do the job
– Do not modify major goals and objectives, once they are defined, unless
absolutely necessary
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 57
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
– Give the team as much responsibility for decision making as possible
– Let the team recommend its own process model
– Let the team establish its own mechanisms for accountability (i.e., reviews)
– Establish team-based techniques for feedback and problem solving
The People: Coordination and Communication Issues
• Key characteristics of modern software make projects fail
– scale, uncertainty, interoperability
• To better ensure success
– Establish effective methods for coordinating the people who do the work
– Establish methods of formal and information communication among team
members
Group Dynamics
• Based on studies published by B. Tuckman in 1965
• Updated later in 1977
• Describes a four-stage model
– Forming
– Storming
– Norming
– Performing
• Forming
– Group members rely on safe, patterned behavior and look to the group leader for
guidance and direction
– Impressions are gathered and similarities and differences are noted
– Serious topics and feelings are avoided
– To grow, members must relinquish the comfort of non-threatening topics and risk
the possibility of conflict
• Storming
– As group members organize for the tasks, conflict inevitably results in their
personal relations and cliques start to form
– Individuals have to bend and mold their feelings to fit the group
– Fear of exposure or fear of failure causes an increased desire for structural
clarification and commitment
– Conflicts arise over leadership, structure, power, and authority
– Member behavior may have wide swings based on emerging issues of
competition and hostilities
– Some members remain silent while others attempt to dominate
• Norming
– Members engage in active acknowledgement of all members’ contributions,
community building, and solving of group issues
– Members are willing to change their preconceived ideas or opinions based on
facts presented by the group
– Leadership is shared, active listening occurs, and cliques dissolve
– Members began to identify with one another, which leads to a level of trust in
their personal relations and contributes to cohesion
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 58
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
– Members begin to experience a sense of group belonging
• Performing
– The capacity, range, and depth of personal relations in the group expand to true
interdependence
– Members can work independently, in subgroups, or altogether with equal ability
and success
– The group is most productive, members become self-assuring, and the need for
group approval is past
– Genuine problem solving can occur leading towards optimal solutions
The Product
• The scope of the software development must be established and bounded
– Context – How does the software to be built fit into a larger system, product, or
business context, and what constraints are imposed as a result of the context?
– Information objectives – What customer-visible data objects are produced as
output from the software? What data objects are required for input?
– Function and performance – What functions does the software perform to
transform input data into output? Are there any special performance
characteristics to be addressed?
• Software project scope must be unambiguous and understandable at both the managerial
and technical levels
• Problem decomposition
– Also referred to as partitioning or problem elaboration
– Sits at the core of software requirements analysis
• Two major areas of problem decomposition
– The functionality that must be delivered
– The process that will be used to deliver it
The Process
•
Getting Started
– The project manager must decide which process model is most appropriate based
on
• The customers who have requested the product and the people who will do
the work
• The characteristics of the product itself
• The project environment in which the software team works
– Once a process model is selected, a preliminary project plan is established based
on the process framework activities
– Process decomposition then begins
– The result is a complete plan reflecting the work tasks required to populate the
framework activities
• Project planning begins as a melding of the product and the process based on the various
framework activities
The Project: A Common Sense Approach
• Start on the right foot
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 59
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
–
Understand the problem; set realistic objectives and expectations; form a good
team
• Maintain momentum
– Provide incentives to reduce turnover of people; emphasize quality in every task;
have senior management stay out of the team’s way
• Track progress
– Track the completion of work products; collect software process and project
measures; assess progress against expected averages
• Make smart decisions
– Keep it simple; use COTS or existing software before writing new code; follow
standard approaches; identify and avoid risks; always allocate more time than you
think you need to do complex or risky tasks
• Conduct a post mortem analysis
– Track lessons learned for each project; compare planned and actual schedules;
collect and analyze software project metrics; get feedback from teams members
and customers; record findings in written form
The Project: Signs that it is in risk
• Software people don't understand their customer's needs
• The product scope is poorly defined
• Changes are managed poorly
• The chosen technology changes
• Business needs change (or are poorly defined)
• Deadlines are unrealistic
• Users are resistant
• Sponsorship is lost (or was never properly obtained)
• The project team lacks people with appropriate skills
• Managers (and practitioners) avoid best practices and lessons learned
The Project: The W5HH Principle
A series of questions that lead to a definition of key project characteristics
and the resultant project plan
• Why is the system being developed?
– Assesses the validity of business reasons and justifications
• What will be done?
– Establishes the task set required for the project
• When will it be done?
– Establishes a project schedule
• Who is responsible for a function?
– Defines the role and responsibility of each team member
• Where are they organizationally located?
– Notes the organizational location of team members, customers, and other
stakeholders
• How will the job be done technically and managerially?
– Establishes the management and technical strategy for the project
• How much of each resource is needed?
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 60
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
–
Establishes estimates based on the answers to the previous questions
19. Explain the software metrics in detail
What are Metrics?
• Software process and project metrics are quantitative measures
• They are a management tool
• They offer insight into the effectiveness of the software process and the projects that are
conducted using the process as a framework
• Basic quality and productivity data are collected
• These data are analyzed, compared against past averages, and assessed
• The goal is to determine whether quality and productivity improvements have occurred
• The data can also be used to pinpoint problem areas
• Remedies can then be developed and the software process can be improved
Uses of Measurement
• Can be applied to the software process with the intent of improving it on a continuous
basis
• Can be used throughout a software project to assist in estimation, quality control,
productivity assessment, and project control
• Can be used to help assess the quality of software work products and to assist in tactical
decision making as a project proceeds
Reasons to Measure
• To characterize in order to
– Gain an understanding of processes, products, resources, and environments
– Establish baselines for comparisons with future assessments
• To evaluate in order to
– Determine status with respect to plans
• To predict in order to
– Gain understanding of relationships among processes and products
– Build models of these relationships
• To improve in order to
– Identify roadblocks, root causes, inefficiencies, and other opportunities for
improving product quality and process performance
Metrics in the Process Domain
• Process metrics are collected across all projects and over long periods of time
• They are used for making strategic decisions
• The intent is to provide a set of process indicators that lead to long-term software process
improvement
• The only way to know how/where to improve any process is to
– Measure specific attributes of the process
– Develop a set of meaningful metrics based on these attributes
– Use the metrics to provide indicators that will lead to a strategy for improvement
• We measure the effectiveness of a process by deriving a set of metrics based on outcomes
of the process such as
– Errors uncovered before release of the software
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 61
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
– Defects delivered to and reported by the end users
– Work products delivered
– Human effort expended
– Calendar time expended
– Conformance to the schedule
– Time and effort to complete each generic activity
Etiquette (good manner) of Process Metrics
• Use common sense and organizational sensitivity when interpreting metrics data
• Provide regular feedback to the individuals and teams who collect measures and metrics
• Don’t use metrics to evaluate individuals
• Work with practitioners and teams to set clear goals and metrics that will be used to
achieve them
• Never use metrics to threaten individuals or teams
• Metrics data that indicate a problem should not be considered “negative”
– Such data are merely an indicator for process improvement
• Don’t obsess on a single metric to the exclusion of other important metrics
Metrics in the Project Domain
• Project metrics enable a software project manager to
– Assess the status of an ongoing project
– Track potential risks
– Uncover problem areas before their status becomes critical
– Adjust work flow or tasks
– Evaluate the project team’s ability to control quality of software work products
• Many of the same metrics are used in both the process and project domain
• Project metrics are used for making tactical decisions
– They are used to adapt project workflow and technical activities
Use of Project Metrics
• The first application of project metrics occurs during estimation
– Metrics from past projects are used as a basis for estimating time and effort
• As a project proceeds, the amount of time and effort expended are compared to original
estimates
• As technical work commences, other project metrics become important
– Production rates are measured (represented in terms of models created, review
hours, function points, and delivered source lines of code)
– Error uncovered during each generic framework activity (i.e, communication,
planning, modeling, construction, deployment) are measured
• Project metrics are used to
– Minimize the development schedule by making the adjustments necessary to
avoid delays and mitigate potential problems and risks
– Assess product quality on an ongoing basis and, when necessary, to modify the
technical approach to improve quality
• In summary
– As quality improves, defects are minimized
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 62
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
–
As defects go down, the amount of rework required during the project is also
reduced
– As rework goes down, the overall project cost is reduced
Categories of Software Measurement
• Two categories of software measurement
– Direct measures of the
• Software process (cost, effort, etc.)
• Software product (lines of code produced, execution speed, defects
reported over time, etc.)
– Indirect measures of the
• Software product (functionality, quality, complexity, efficiency,
reliability, maintainability, etc.)
• Project metrics can be consolidated to create process metrics for an organization
Size-oriented Metrics
• Derived by normalizing quality and/or productivity measures by considering the size of
the software produced
• Thousand lines of code (KLOC) are often chosen as the normalization value
• Metrics include
– Errors per KLOC
- Errors per person-month
– Defects per KLOC
- KLOC per person-month
– Dollars per KLOC
- Dollars per page of documentation
– Pages of documentation per KLOC
• Size-oriented metrics are not universally accepted as the best way to measure the
software process
• Opponents argue that KLOC measurements
– Are dependent on the programming language
– Penalize well-designed but short programs
– Cannot easily accommodate nonprocedural languages
– Require a level of detail that may be difficult to achieve
Function-oriented Metrics
• Function-oriented metrics use a measure of the functionality delivered by the application
as a normalization value
• Most widely used metric of this type is the function point:
FP = count total * [0.65 + 0.01 * sum (value adj. factors)]
• Material in Chapter 15 covered this in more detail
• Function point values on past projects can be used to compute, for example, the average
number of lines of code per function point (e.g., 60)
Function Point Controversy
• Like the KLOC measure, function point use also has proponents and opponents
• Proponents claim that
• FP is programming language independent
• FP is based on data that are more likely to be known in the early stages of a
project, making it more attractive as an estimation approach
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 63
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
•
Opponents claim that
• FP requires some “sleight of hand” because the computation is based on
subjective data
• Counts of the information domain can be difficult to collect after the fact
• FP has no direct physical meaning…it’s just a number
• Relationship between LOC and FP depends upon
• The programming language that is used to implement the software
• The quality of the design
• FP and LOC have been found to be relatively accurate predictors of software
development effort and cost
• However, a historical baseline of information must first be established
• LOC and FP can be used to estimate object-oriented software projects
• However, they do not provide enough granularity for the schedule and effort
adjustments required in the iterations of an evolutionary or incremental process
• The table on the next slide provides a rough estimate of the average LOC to one
FP in various programming languages
Language
Average
Median
Low
High
Ada
154
--
104
205
Assembler
337
315
91
694
C
162
109
33
704
C++
66
53
29
178
COBOL
77
77
14
400
Java
55
53
9
214
PL/1
78
67
22
263
Visual
Basic
47
42
16
158
Metrics for Software Quality
•
•
Correctness
– This is the number of defects per KLOC, where a defect is a verified lack of
conformance to requirements
– Defects are those problems reported by a program user after the program is
released for general use
Maintainability
– This describes the ease with which a program can be corrected if an error is
found, adapted if the environment changes, or enhanced if the customer has
changed requirements
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 64
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
–
Mean time to change (MTTC) : the time to analyze, design, implement, test, and
distribute a change to all users
• Maintainable programs on average have a lower MTTC
Establishing a Metrics Baseline
•
•
•
•
•
By establishing a metrics baseline, benefits can be obtained at the software process,
product, and project levels
The same metrics can serve many masters
The baseline consists of data collected from past projects
Baseline data must have the following attributes
– Data must be reasonably accurate (guesses should be avoided)
– Data should be collected for as many projects as possible
– Measures must be consistent (e.g., a line of code must be interpreted consistently
across all projects)
– Past applications should be similar to the work that is to be estimated
After data is collected and metrics are computed, the metrics should be evaluated and
applied during estimation, technical work, project control, and process improvement
Software Metrics Baseline Process
1) Understand your existing process
2) Define the goals to be achieved by establishing a metrics program
3) Identify metrics to achieve those goals
– Keep the metrics simple
– Be sure the metrics add value to your process and product
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 65
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
4) Identify the measures to be collected to support those metrics
5) Establish a measurement collection process
– What is the source of the data?
– Can tools be used to collect the data?
– Who is responsible for collecting the data?
– When are the data collected and recorded?
– How are the data stored?
– What validation mechanisms are used to ensure the data are correct?
6) Acquire appropriate tools to assist in collection and assessment
7) Establish a metrics database
8) Define appropriate feedback mechanisms on what the metrics indicate about your process
so that the process and the metrics program can be improved
20. Explain the methods carried out in project scheduling
Eight Reasons for Late Software Delivery
• An unrealistic deadline established by someone outside the software engineering group
and forced on managers and practitioners within the group
• Changing customer requirements that are not reflected in schedule changes
• An honest underestimate of the amount of effort and /or the number of resources that will
be required to do the job
• Predictable and/or unpredictable risks that were not considered when the project
commenced
• Technical difficulties that could not have been foreseen in advance
• Human difficulties that could not have been foreseen in advance
• Miscommunication among project staff that results in delays
• A failure by project management to recognize that the project is falling behind schedule
and a lack of action to correct the problem
Handling Unrealistic Deadlines
• Perform a detailed estimate using historical data from past projects; determine the
estimated effort and duration for the project
• Using an incremental model, develop a software engineering strategy that will deliver
critical functionality by the imposed deadline, but delay other functionality until later;
document the plan
• Meet with the customer and (using the detailed estimate) explain why the imposed
deadline is unrealistic
– Be certain to note that all estimates are based on performance on past projects
– Also be certain to indicate the percent improvement that would be required to
achieve the deadline as it currently exists
1) Offer the incremental development strategy as an alternative and offer some options
– Increase the budget and bring on additional resources to try to finish sooner
– Remove many of the software functions and capabilities that were requested
– Dispense with reality and wish the project complete using the prescribed
schedule; then point out that project history and your estimates show that this is
unrealistic and will result in a disaster
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 66
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
Project Scheduling
• On large projects, hundreds of small tasks must occur to accomplish a larger goal
– Some of these tasks lie outside the mainstream and may be completed without
worry of impacting on the project completion date
– Other tasks lie on the critical path; if these tasks fall behind schedule, the
completion date of the entire project is put into jeopardy
• Project manager's objectives
– Define all project tasks
– Build an activity network that depicts their interdependencies
– Identify the tasks that are critical within the activity network
– Build a timeline depicting the planned and actual progress of each task
– Track task progress to ensure that delay is recognized "one day at a time"
– To do this, the schedule should allow progress to be monitored and the project to
be controlled
• Software project scheduling distributes estimated effort across the planned project
duration by allocating the effort to specific tasks
• During early stages of project planning, a macroscopic schedule is developed identifying
all major process framework activities and the product functions to which they apply
• Later, each task is refined into a detailed schedule where specific software tasks are
identified and scheduled
• Scheduling for projects can be viewed from two different perspectives
– In the first view, an end-date for release of a computer-based system has already
been established and fixed
• The software organization is constrained to distribute effort within the
prescribed time frame
– In the second view, assume that rough chronological bounds have been discussed
but that the end-date is set by the software engineering organization
• Effort is distributed to make best use of resources and an end-date is
defined after careful analysis of the software
– The first view is encountered far more often that the second
Principles for Project Scheduling
• Compartmentalization
– The project must be compartmentalized into a number of manageable activities,
actions, and tasks; both the product and the process are decomposed
• Interdependency
– The interdependency of each compartmentalized activity, action, or task must be
determined
– Some tasks must occur in sequence while others can occur in parallel
– Some actions or activities cannot commence until the work product produced by
another is available
• Time allocation
– Each task to be scheduled must be allocated some number of work units
– In addition, each task must be assigned a start date and a completion date that are
a function of the interdependencies
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 67
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
–
Start and stop dates are also established based on whether work will be conducted
on a full-time or part-time basis
• Effort validation
– Every project has a defined number of people on the team
– As time allocation occurs, the project manager must ensure that no more than the
allocated number of people have been scheduled at any given time
• Defined responsibilities
– Every task that is scheduled should be assigned to a specific team member
• Defined outcomes
– Every task that is scheduled should have a defined outcome for software projects
such as a work product or part of a work product
– Work products are often combined in deliverables
• Defined milestones
– Every task or group of tasks should be associated with a project milestone
– A milestone is accomplished when one or more work products has been reviewed
for quality and has been approved
Relationship Between People and Effort
• Common management myth: If we fall behind schedule, we can always add more
programmers and catch up later in the project
– This practice actually has a disruptive effect and causes the schedule to slip even
further
– The added people must learn the system
– The people who teach them are the same people who were earlier doing the work
– During teaching, no work is being accomplished
– Lines of communication (and the inherent delays) increase for each new person
added
Effort Applied vs. Delivery Time
•
•
There is a nonlinear relationship between effort applied and delivery time (Ref: PutnamNorden-Rayleigh Curve)
– Effort increases rapidly as the delivery time is reduced
Also, delaying project delivery can reduce costs significantly as shown in the equation E
= L3/(P3t4) and in the curve below
– E = development effort in person-months
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 68
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
– L = source lines of code delivered
– P = productivity parameter (ranging from 2000 to 12000)
– t = project duration in calendar months
40-20-40 Distribution of Effort
• A recommended distribution of effort across the software process is 40% (analysis and
design), 20% (coding), and 40% (testing)
• Work expended on project planning rarely accounts for more than 2 - 3% of the total
effort
• Requirements analysis may comprise 10 - 25%
– Effort spent on prototyping and project complexity may increase this
• Software design normally needs 20 – 25%
• Coding should need only 15 - 20% based on the effort applied to software design
• Testing and subsequent debugging can account for 30 - 40%
– Safety or security-related software requires more time for testing
Example: 100-day project
Task Network
Defining a Task Set
• A task set is the work breakdown structure for the project
• No single task set is appropriate for all projects and process models
– It varies depending on the project type and the degree of rigor (based on
influential factors) with which the team plans to work
• The task set should provide enough discipline to achieve high software quality
– But it must not burden the project team with unnecessary work
Types of Software Projects
•
•
•
•
•
Concept development projects
– Explore some new business concept or application of some new technology
New application development
– Undertaken as a consequence of a specific customer request
Application enhancement
– Occur when existing software undergoes major modifications to function,
performance, or interfaces that are observable by the end user
Application maintenance
– Correct, adapt, or extend existing software in ways that may not be immediately
obvious to the end user
Reengineering projects
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 69
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
–
Undertaken with the intent of rebuilding an existing (legacy) system in whole or
in part
Concept development projects are approached by applying the following actions:
1.1 Concept scoping determines the overall scope of the project.
1.2 Preliminary concept planning establishes the organization’s ability to undertake the work
implied by the project scope.
1.3 Technology risk assessment evaluates the risk associated with the technology to be
implemented as part of the project scope.
1.4 Proof of concept demonstrates the viability of a new technology in the software context.
1.5 Concept implementation implements the concept representation in a manner that can be
reviewed by a customer and is used for “marketing” purposes when a concept must be sold to
other customers or management.
1.6 Customer reaction to the concept solicits feedback on a new technology concept and targets
specific customer applications.
A process design language approach is used to illustrate the flow of the concept scoping
action:
Task definition: Action 1.1 Concept Scoping
1.1.1 Identify need, benefits and potential customers;
1.1.2 Define desired output/control and input events that drive the application;
Begin Task 1.1.2
1.1.2.1 TR: Review written description of need7
1.1.2.2 Derive a list of customer visible outputs/inputs
1.1.2.3 TR: Review outputs/inputs with customer and revise as required; endtask
Task 1.1.2
1.1.3 Define the functionality/behavior for each major function;
Begin Task 1.1.3
1.1.3.1 TR: Review output and input data objects derived in task 1.1.2;
1.1.3.2 Derive a model of functions/behaviors;
1.1.3.3 TR: Review functions/behaviors with customer and revise as required;
endtask Task 1.1.3
1.1.4 Isolate those elements of the technology to be implemented in software;
1.1.5 Research availability of existing software;
1.1.6 Define technical feasibility;
1.1.7 Make quick estimate of size;
1.1.8 Create a scope definition;
Endtask definition: Action 1.1
Factors that Influence a Project’s Schedule
• Size of the project
• Number of potential users
• Mission criticality
• Application longevity
• Stability of requirements
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 70
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
• Ease of customer/developer communication
• Maturity of applicable technology
• Performance constraints
• Embedded and non-embedded characteristics
• Project staff
• Reengineering factors
Purpose of a Task Network
• Also called an activity network
• It is a graphic representation of the task flow for a project
• It depicts task length, sequence, concurrency, and dependency
• Points out inter-task dependencies to help the manager ensure continuous progress
toward project completion
• The critical path
– A single path leading from start to finish in a task network
– It contains the sequence of tasks that must be completed on schedule if the project
as a whole is to be completed on schedule
– It also determines the minimum duration of the project
• All project tasks are listed in the far left column
• The next few columns may list the following for each task: projected start date, projected
stop date, projected duration, actual start date, actual stop date, actual duration, task interdependencies (i.e., predecessors)
• To the far right are columns representing dates on a calendar
• The length of a horizontal bar on the calendar indicates the duration of the task
• When multiple bars occur at the same time interval on the calendar, this implies task
concurrency
• A diamond in the calendar area of a specific task indicates that the task is a milestone; a
milestone has a time duration of zero
Figure 1.1 illustrates the format of a time-line chart. It depicts a part of a software project
schedule that emphasizes the concept scoping task for a word-processing (WP) software product.
All project tasks (for concept scoping) are listed in the left hand column. The horizontal bars
indicate the duration of each task. When multiple bars occur at the same time on the calendar,
task concurrency is implied. The diamonds indicate milestones.
Once the information necessary for the generation of a time-line chart has been input, the
majority of software project scheduling tools produce project tables—a tabular listing of all
project tasks, their planned and actual start and end dates, and a variety of related information in
figure 1.2
Fig-1.1: A task network for concept development
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 71
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
An example Time-line chart
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 72
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING UNIT I SOFTWARE
PROCESS AND PROJECT MANAGEMENT
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 73
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING UNIT I SOFTWARE
PROCESS AND PROJECT MANAGEMENT
Figure 1.2: An example project table
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 74
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING UNIT I SOFTWARE
PROCESS AND PROJECT MANAGEMENT
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 75
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING UNIT I SOFTWARE
PROCESS AND PROJECT MANAGEMENT
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 76
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
Methods for Tracking the Schedule
•
Qualitative approaches
– Conduct periodic project status meetings in which each team member reports
progress and problems
– Evaluate the results of all reviews conducted throughout the software engineering
process
– Determine whether formal project milestones (i.e., diamonds) have been
accomplished by the scheduled date
– Compare actual start date to planned start date for each project task listed in the
timeline chart
– Meet informally with the software engineering team to obtain their subjective
assessment of progress to date and problems on the horizon
• Quantitative approach
– Use earned value analysis to assess progress quantitatively
Project Control and Time Boxing
• The project manager applies control to administer project resources, cope with problems,
and direct project staff
• If things are going well (i.e., schedule, budget, progress, milestones) then control should
be light
• When problems occur, the project manager must apply tight control to reconcile the
problems as quickly as possible. For example:
– Staff may be redeployed
– The project schedule may be redefined
• Severe deadline pressure may require the use of time boxing
– An incremental software process is applied to the project
– The tasks associated with each increment are “time-boxed” (i.e., given a specific
start and stop time) by working backward from the delivery date
– The project is not allowed to get “stuck” on a task
– When the work on a task hits the stop time of its box, then work ceases on that
task and the next task begins
– This approach succeeds based on the premise that when the time-box boundary is
encountered, it is likely that 90% of the work is complete
– The remaining 10% of the work can be
• Delayed until the next increment
• Completed later if required
Tracking Progress on an OO Project
 Technical milestone: OO analysis completed
• All classes and the class hierarchy have been defined and reviewed.
• Class attributes and operations associated with a class have been defined
and reviewed.
• Class relationships (Chapter 8) have been established and reviewed.
• A behavioral model (Chapter 8) has been created and reviewed.
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 77
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
• Reusable classes have been noted.
 Technical milestone: OO design completed
• The set of subsystems (Chapter 9) has been defined and reviewed.
• Classes are allocated to subsystems and reviewed.
• Task allocation has been established and reviewed.
• Responsibilities and collaborations (Chapter 9) have been identified.
• Attributes and operations have been designed and reviewed.
• The communication model has been created and reviewed.
 Technical milestone: OO programming completed
• Each new class has been implemented in code from the design model.
• Extracted classes (from a reuse library) have been implemented.
• Prototype or increment has been built.
 Technical milestone: OO testing
• The correctness and completeness of OO analysis and design models has
been reviewed.
• A class-responsibility-collaboration network (Chapter 6) has been
developed and reviewed.
• Test cases are designed and class-level tests (Chapter 19) have been
conducted for each class.
• Test cases are designed and cluster testing (Chapter 19) is completed and
the classes are integrated.
• System level tests have been completed.
Scheduling for WebApp Projects
WebApp project scheduling distributes estimated effort across the planned time line
(duration) for building each WebApp increment. This is accomplished by allocating the effort to
specific tasks. It is important to note, however, that the overall WebApp schedule evolves over
time. During the first iteration, a macroscopic schedule is developed. This type of schedule
identifies all WebApp increments and projects the dates on which each will be deployed. As the
development of an increment gets under way, the entry for the increment on the macroscopic
schedule is refined into a detailed schedule. Here, specific development tasks (required to
accomplish an activity) are identified and scheduled.
As an example of macroscopic scheduling, consider the SafeHomeAssured.com
WebApp. Recalling earlier discussions of SafeHomeAssured.com, seven increments can be
identified for the Web-based component of the project:
 Increment 1: Basic company and product information
 Increment 2: Detailed product information and downloads
 Increment 3: Product quotes and processing product orders
 Increment 4: Space layout and security system design
 Increment 5: Information and ordering of monitoring services
 Increment 6: Online control of monitoring equipment
 Increment 7: Accessing account information
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 78
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
Time line for macroscopic project schedule
It is important to note that the deployment dates (represented by diamonds on the timeline chart) are preliminary and may change as more detailed scheduling of the increments occurs.
However, this macroscopic schedule provides management with an indication of when content
and functionality will be available and when the entire project will be completed. As a
preliminary estimate, the team will work to deploy all increments with a 12-week time line. It’s
also worth noting that some of the increments will be developed in parallel (e.g., increments 3, 4,
6 and 7). This assumes that the team will have sufficient people to do this parallel work.
Once the macroscopic schedule has been developed, the team is ready to schedule work
tasks for a specific increment. To accomplish this, you can use a generic process framework that
is applicable for all WebApp increments. A task list is created by using the generic tasks derived
as part of the framework as a starting point and then adapting these by considering the content
and functions to be derived for a specific WebApp increment.
Each framework action (and its related tasks) can be adapted in one of four ways:
a. a task is applied as is,
b. a task is eliminated because it is not necessary for the increment,
c. a new (custom) task is added, and
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 79
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
d. a task is refined (elaborated) into a number of named subtasks that each becomes part
of the schedule.
To illustrate, consider a generic design modeling action for WebApps that can be
accomplished by applying some or all of the following tasks:
 Design the aesthetic for the WebApp.
 Design the interface.
 Design the navigation scheme.
 Design the WebApp architecture.
 Design the content and the structure that supports it.
 Design functional components.
 Design appropriate security and privacy mechanisms.
 Review the design.
As an example, consider the generic task Design the Interface as it is applied to the fourth
increment of SafeHomeAssured.com. The team recognizes that the interface design is pivotal
to the success of the increment and decides to refine (elaborate) the task. The following subtasks
are derived for the
Design the Interface task for the fourth increment:
• Develop a sketch of the page layout for the space design page.
• Review layout with stakeholders.
• Design space layout navigation mechanisms.
• Design “drawing board” layout.10
• Develop procedural details for the graphical wall layout function.
• Develop procedural details for the wall length computation and display function.
• Develop procedural details for the graphical window layout function.
• Develop procedural details for the graphical door layout function.
• Design mechanisms for selecting security system components (sensors, cameras,
microphones, etc.).
• Conduct pair walkthroughs as required.
These tasks become part of the increment schedule for the fourth WebApp increment and are
allocated over the increment development schedule. They can be input to scheduling software
and used for tracking and control.
Description of Earned Value Analysis
• Earned value analysis is a measure of progress by assessing the percent of completeness
for a project
• It gives accurate and reliable readings of performance very early into a project
• It provides a common value scale (i.e., time) for every project task, regardless of the type
of work being performed
• The total hours to do the whole project are estimated, and every task is given an earned
value based on its estimated percentage of the total
Determining Earned Value
• The budgeted cost of work scheduled (BCWS) is determined for each work task
represented in the schedule.
• BCWSi is the effort planned for work task i.
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 80
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
•
•
To determine progress at a given point along the project schedule, the value of BCWS is
the sum of the BCWSi values for all work tasks that should have been completed by that
point in time on the project schedule.
The BCWS values for all work tasks are summed to derive the budget at completion,
BAC. Hence,
BAC = ∑ (BCWSk) for all tasks k
•
•
•
•
Next, the value for budgeted cost of work performed (BCWP) is computed.
The value for BCWP is the sum of the BCWS values for all work tasks that have actually
been completed by a point in time on the project schedule.
“the distinction between the BCWS and the BCWP is that the former represents the
budget of the activities that were planned to be completed and the latter represents the
budget of the activities that actually were completed.” [Wil99]
Given values for BCWS, BAC, and BCWP, important progress indicators can be
computed:
– Schedule performance index
SPI = BCWP/BCWS
–
•
•
•
•
•
•
•
•
Schedule variance,
SV = BCWP – BCWS
SPI is an indication of the efficiency with which the project is utilizing scheduled
resources.
Compute the budgeted cost of work scheduled (BCWS) for each work task i in the
schedule
– The BCWS is the effort planned; work is estimated in person-hours or persondays for each task
– To determine progress at a given point along the project schedule, the value of
BCWS is the sum of the BCWSi values of all the work tasks that should have
been completed by that point of time in the project schedule
Sum up the BCWS values for all work tasks to derive the budget at completion (BAC)
Compute the value for the budgeted cost of work performed (BCWP)
– BCWP is the sum of the BCWS values for all work tasks that have actually been
completed by a point of time on the project schedule
Percent scheduled for completion = BCWS/BAC
– provides an indication of the percentage of work that should have been completed
by time t.
Percent complete = BCWP/BAC
– provides a quantitative indication of the percent of completeness of the project at
a given point in time, t.
Actual cost of work performed, ACWP, is the sum of the effort actually expended on
work tasks that have been completed by a point in time on the project schedule. It is then
possible to compute
Cost performance index, CPI = BCWP/ACWP
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 81
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
•
Cost variance, CV = BCWP – ACWP
21. Explain various software size estimation techniques in detail
The overall goal of project planning is to establish a pragmatic strategy for controlling,
tracking, and monitoring a complex technical project.
Project Planning Task Set
 Establish project scope
 Determine feasibility
 Analyze risks
 Risk analysis is considered in detail in Chapter 25.
 Define required resources
 Determine require human resources
 Define reusable software resources
 Identify environmental resources
 Estimate cost and effort
 Decompose the problem
 Develop two or more estimates using size, function points, process tasks or usecases
 Reconcile the estimates
 Develop a project schedule
 Establish a meaningful task set
 Define a task network
 Use scheduling tools to develop a timeline chart
 Define schedule tracking mechanisms
Project Estimation
 Estimation of resources, cost, and schedule for a software engineering effort requires
 experience
 access to good historical information (metrics)
 the courage to commit to quantitative predictions when qualitative information is
all that exists
 Estimation carries inherent risk and this risk leads to uncertainty
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 82
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
To Understand Scope
 Understand the customer’s needs
 understand the business context
 understand the project boundaries
 understand the customer’s motivation
 understand the likely paths for change
 Software scope describes
 the functions and features that are to be delivered to end-users
 the data that are input and output
 the “content” that is presented to users as a consequence of using the software
 the performance, constraints, interfaces, and reliability that bound the system.
 Scope is defined using one of two techniques:
 A narrative description of software scope is developed after
communication with all stakeholders.
 A set of use-cases is developed by end-users.
Resources
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 83
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
software
tools
number
skills
hardware
people
environment
location
network
resources
project
OTS
components
reusable
software
full-experience
components
new
components
part.-experience
components
The planner begins by evaluating software scope and selecting the skills required to
complete development. Both organizational position (e.g., manager, senior software engineer)
and specialty (e.g., telecommunications, database, client-server) are specified. For relatively
small projects (a few person-months), a single individual may perform all software engineering
tasks, consulting with specialists as required. For larger projects, the software team may be
geographically dispersed across a number of different locations. Hence, the location of each
human resource is specified.
The number of people required for a software project can be determined only after an
estimate of development effort (e.g., person-months) is made. Techniques for estimating effort
are discussed later in this chapter.
Reusable Software Resources
Component-based software engineering (CBSE) emphasizes reusability—that is, the
creation and reuse of software building blocks. Such building blocks, often called components,
must be cataloged for easy reference, standardized for easy application, and validated for easy
integration.
Bennatan suggests four software resource categories that should be considered as
planning proceeds:
 Off-the-shelf components. Existing software that can be acquired from a third party or from
a past project. COTS (commercial off-the-shelf) components are purchased from a third
party, are ready for use on the current project, and have been fully validated.
 Full-experience components. Existing specifications, designs, code, or test data developed
for past projects that are similar to the software to be built for the current project. Members
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 84
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
of the current software team have had full experience in the application area represented by
these components. Therefore, modifications required for full-experience components will be
relatively low risk.
 Partial-experience components. Existing specifications, designs, code, or test data
developed for past projects that are related to the software to be built for the current project
but will require substantial modification. Members of the current software team have only
limited experience in the application area represented by these components. Therefore,
modifications required for partial-experience components have a fair degree of risk.
 New components. Software components must be built by the software team specifically for
the needs of the current project.
Environmental Resources
The environment that supports a software project, often called the software engineering
environment (SEE), incorporates hardware and software. Hardware provides a platform that
supports the tools (software) required to produce the work products that are an outcome of good
software engineering practice.
When a computer-based system (incorporating specialized hardware and software) is to
be engineered, the software team may require access to hardware elements being developed by
other engineering teams. For example, software for a robotic device used within a manufacturing
cell may require a specific robot (e.g., a robotic welder) as part of the validation test step; a
software project for advanced page layout may need a high-speed digital printing system at some
point during development. Each hardware element must be specified as part of planning.
Project Estimation
Software cost and effort estimation will never be an exact science. Too many variables—
human, technical, environmental, political—can affect the ultimate cost of software and effort
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 85
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
applied to develop it. However, software project estimation can be transformed from a black art
to a series of systematic steps that provide estimates with acceptable risk.
To achieve reliable cost and effort estimates, a number of options arise:
1) Delay estimation until late in the project (obviously, we can achieve 100 percent accurate
estimates after the project is complete!).
2) Base estimates on similar projects that have already been completed.
3) Use relatively simple decomposition techniques to generate project cost and effort estimates.
4) Use one or more empirical models for software cost and effort estimation.
• Option #1 is not practical, but results in good numbers
• Option #2 can work reasonably well, but it also relies on other project influences being
roughly equivalent
• Options #3 and #4 can be done in tandem to cross check each other
Estimation Techniques
 Past (similar) project experience
 Conventional or Decomposition techniques
 These take a "divide and conquer" approach
 Cost and effort estimation are performed in a stepwise fashion by breaking down
a project into major functions and related software engineering activities
 Empirical estimation models
 Offer a potentially valuable estimation approach if the historical data used to seed
the estimate is good
 Automated tools
Decomposition Techniques
•
Before an estimate can be made and decomposition techniques applied, the planner must
– Understand the scope of the software to be built
– Generate an estimate of the software’s size
• Then one of two approaches are used
– Problem-based estimation
• Based on either source lines of code or function point estimates
– Process-based estimation
• Based on the effort required to accomplish each task
Software project estimation is a form of problem solving, and in most cases, the problem
to be solved (i.e., developing a cost and effort estimate for a software project) is too complex to
be considered in one piece.
software sizing
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 86
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
The Estimation Accuracy is Predicated on
 the degree to which the planner has properly estimated the size of the product to
be built
 the ability to translate the size estimate into human effort, calendar time, and
dollars (a function of the availability of reliable software metrics from past
projects)
 the degree to which the project plan reflects the abilities of the software team
 the stability of product requirements and the environment that supports the
software engineering effort.
Consider the software sizing problem. Because a project estimate is only as good as the
estimate of the size of the work to be accomplished, sizing represents your first major challenge
as a planner. In the context of project planning, size refers to a quantifiable outcome of the
software project. If a direct approach is taken, size can be measured in lines of code (LOC). If an
indirect approach is chosen, size is represented as function points (FP).
Putnam and Myers [Put92] suggest four different approaches to the sizing problem:
• “Fuzzy logic” sizing. This approach uses the approximate reasoning techniques that are
the cornerstone of fuzzy logic. To apply this approach, the planner must identify the type
of application, establish its magnitude on a qualitative scale, and then refine the
magnitude within the original range.
• Function point sizing. The planner develops estimates of the information domain
characteristics
• Standard component sizing. Software is composed of a number of different “standard
components” that are generic to a particular application area. For example, the standard
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 87
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
components for an information system are subsystems, modules, screens, reports,
interactive programs, batch programs, files, LOC, and object-level instructions. The
project planner estimates the number of occurrences of each standard component and
then uses historical project data to estimate the delivered size per standard component.
• Change sizing. This approach is used when a project encompasses the use of existing
software that must be modified in some way as part of a project. The planner estimates
the number and type (e.g., reuse, adding code, changing code, deleting code) of
modifications that must be accomplished.
The results of these estimates are used to compute an optimistic (low), a most likely,
and a pessimistic (high) value for software size
Problem-Based Estimation
1) Start with a bounded statement of scope
2) Decompose the software into problem functions that can each be estimated individually
3) Compute an LOC or FP value for each function
4) Derive cost or effort estimates by applying the LOC or FP values to your baseline
productivity metrics (e.g., LOC/person-month or FP/person-month)
5) Combine function estimates to produce an overall estimate for the entire project
 In general, the LOC/pm and FP/pm metrics should be computed by project domain
 Important factors are team size, application area, and complexity
 LOC and FP estimation differ in the level of detail required for decomposition with each
value
 For LOC, decomposition of functions is essential and should go into considerable detail
(the more detail, the more accurate the estimate)
 For FP, decomposition occurs for the five information domain characteristics and the 14
adjustment factors
Inputs
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Outputs
Enquirie
s
Internal
Logical
Files
External
Interfac
e Files
Page 88
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
 External inputs, external outputs, external inquiries, internal logical files, external
interface files
 For both approaches, the planner uses lessons learned to estimate an optimistic, most
likely, and pessimistic size value for each function or count (for each information domain
value)
 Then the expected size value S is computed as follows:
S = (Sopt + 4Sm + Spess)/6
 Historical LOC or FP data is then compared to S in order to cross-check it
.
Conventional Methods:
LOC/FP Approach
LOC and FP estimation are distinct estimation techniques.
 compute LOC/FP using estimates of information domain values
 use historical data to build estimates for the project
.
Functional Decomposition
Example: LOC Approach
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 89
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
 For example, the range of LOC estimates for the 3D geometric analysis function is
optimistic, 4600 LOC; most likely, 6900 LOC; and pessimistic, 8600 LOC. the expected
value for the 3D geometric analysis function is 6800 LOC by applying this





S = (Sopt + 4Sm + Spess)/6 = (4600+4X6900+8600)
= 40,800/6 = 6800 LOC
Productivity = size/effort
= KilosLOC/person month
Quality = errors/size
= errors/KLOC
Cost = $/KLOC
Documentation = pages/KLOC
Effort will be given
 Average productivity for systems of this type =
 Burdened labor rate =$8000 per month,
 The cost per line of code is approximately =
33200
54
= 620 LOC/pm.
$8000
620 𝐿𝑂𝐶 𝑝𝑒𝑟𝑠𝑜𝑛 𝑚𝑜𝑛𝑡ℎ
= $12.90 ≈ $13
 Based on the LOC estimate and the historical productivity data,
 The total estimated project cost is = (33200 X 13) = $431,000
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 90
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
 The estimated effort is =
𝒆𝒔𝒕𝒊𝒎𝒂𝒕𝒆𝒅 𝒍𝒊𝒏𝒆 𝒐𝒇 𝒄𝒐𝒅𝒆𝒔
𝟑𝟑𝟐𝟎𝟎
𝒂𝒗𝒆𝒓𝒂𝒈𝒆 𝒑𝒓𝒐𝒅𝒖𝒄𝒕𝒊𝒗𝒊𝒕𝒚
𝟔𝟐𝟎 𝑳𝑶𝑪?𝒑𝒎
= 54 person-months.
Example: FP Approach
Information
Domain Value
opt
likely
pass
Estimated count
Weight
Number of
inputs
Number of
outputs
Number of
inquiries
Number of files
Number of
external
interfaces
Count total
20
24
30
24.33
4
FP count
= estimated count X
weight
97.33
12
15
22
15.66
5
78.3
16
22
28
22
5
110
4
2
4
2
5
3
4.16
2.16
10
7
41.6
15.1
= (Sopt + 4Sm + Spess)/6
342.33
The estimated number of FP is derived:
The factor varies from 0.65 (if each Fi is set to 0) to 1.35 (if each Fi is set to 5)
FPestimated = count total * VAF
VAF= [0.65 + (0.01 * ∑ (Fi))] = .65 + (.01*52) = 1.17
FPestimated = count total * VAF
342 * 1.17 = 400.14 ≈ 400
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 91
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
Where
 The Fi (i = 1 to 14) are value adjustment factors (VAF) based on responses to the
 following questions [Lon02]:

Each of these questions is answered using a scale that ranges from 0 (not important or
applicable) to 5 (absolutely essential)
 Each of the complexity weighting factors is estimated, and the value adjustment factor is
computed FPestimated = 400
 Organizational average productivity =


𝐹𝑃estimated
𝑝𝑒𝑟𝑠𝑜𝑛−𝑚𝑜𝑛𝑡ℎ
=
400
58
= 6.8 FP/pm.
Burdened labor rate = $8000 per month,
The cost per FP count is approximately =
𝑎𝑣𝑒𝑟𝑎𝑔𝑒 𝑙𝑎𝑏𝑜𝑟 𝑟𝑎𝑡𝑒
𝑎𝑣𝑒𝑟𝑎𝑔𝑒 𝑝𝑟𝑜𝑑𝑢𝑐𝑡𝑖𝑣𝑖𝑡𝑦
8000
=
6.8
= $1176/FP.
 Based on the FP estimate and the historical productivity data, total estimated project cost
is $461,000 and estimated effort is 58 person-months.
 The total estimated project cost is = FPestimated * cost /FPcount
= (400 * 1230) = $461,000
Example :
Functional units
External Inputs
External Outputs
External Inquiries
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Low
3
4
3
Average
4
5
4
High
6
7
5
Page 92
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
Internal logical files
(ILF)
External interface
files (EIF)
7
10
15
5
7
10
Consider a project with the following functional units: 50 user inputs,40 user outputs,35 user
enquiries,6 user files,4 external interfaces. Assume all complexity adjustment factors and
weighting factors are average. Compute the function points for the project. Suppose that
program needs 70 LOC per FP. Find out the size of complete project
Unadjusted Function point = 50 × 4 + 40 × 5 + 35 × 4 + 6 × 10 + 4 × 7
= 200 + 200 + 140 + 60 + 28
= 628
FPestimated = count total * VAF
VAF= [0.65 + (0.01 * ∑ (Fi))] = .65 + (.01* 52) = 1.17
FPestimated = count total * VAF
342 * 1.17 = 400.14 ≈ 400
STOCK CONTROL SYSTEM - estimating the time needed to develop application
Let's imagine a company which sells goods on the phone - if agents call the customers,
customers call the agents, and so on - business operates successfully, but there comes a time for
putting the whole in order. There occurs a need for developing a system able to control the whole
stock, from orders to payments. Our thing is to estimate how complex such system can be and
- after that - try to predict how long it would take to develop it.
At first, we should pay attention to the functionality - what exactly the system should be
able to do. Basically, it should be able to take care about three parts - customers, stock, and
transactions.
Then, let us group functions into five categories:
External Inputs - customer, order, stock, and payment details. There are four things we need to
consider.
External Outputs - customer, order, and stock details, and credit rating. Once again, there are
four things to consider.
External Inquiries - the system is requested for three things, which are customer, order, and stock
details.
External Interface Files - there's no EIFs to consider.
Internal Logical Files - finally, the four elements belong to the last group. Customer, and good
files, and customer, and good transaction files.
Let's predict every function's complexity is low, so the values can be presented in a table:
Category
Multiplier
Weight
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 93
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
EI
EO
EQ
ILF
4
4
3
4
3
4
3
7
 Basic" Function Points:
BFP = 4 EI + 5 EO + 4 EQ + 10 ILF + 7 EIF
–
–
–
–
–
–
External inputs (EI): input screens and tables.
External outputs (EO): output screens and reports.
External inquiries (EQ): prompts and interrupts.
Internal files (ILF): databases and directories.
External interfaces (EIF): shared mathematical routines.
(With + / - 25% Complexity Adjustment)
= 4*3+4*4+3*3+4*7=65 [Function Points]
Some sources prove that one function point is an equivalent of eight hours of work in C++
language.
= 65*8=520 [hours]. The estimate for developing the application would take
about 520 hours of work.
Process-Based Estimation
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 94
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
Activity
CC
Planning
Risk
Analysis
Task
Engineering
Construction
Release
analysis
design
code
test
0.50
0.75
0.50
0.50
0.50
0.25
0.50
2.50
4.00
4.00
3.00
3.00
2.00
2.00
0.40
0.60
1.00
1.00
0.75
0.50
0.50
5.00
2.00
3.00
1.50
1.50
1.50
2.00
4.50
16.50
CE
Totals
n/a
n/a
n/a
n/a
n/a
n/a
n/a
8.40
7.35
8.50
6.00
5.75
4.25
5.00
Function
UICF
2DGA
3DGA
CGDF
DSM
PCF
DAM
Totals
0.25
0.25
0.25
3.50
20.50
% effort
1%
1%
1%
8%
45%
10%
46.00
36%
CC = customer communication CE = customer evaluation
TOTAL UICF = 0.50+2.50+0.40+5.00 = 8.40
TOTAL 2DGA = 0.75+4.00+0.60+2.00 = 7.36
TOTAL 3DGA = 0.50+4.00+1.00+3.00 = 8.50
TOTAL CGDF = 0.50+3.00+1.00+1.50 = 6.00
TOTAL DSM = 0.50+3.00+0.75+1.50 = 5.75
TOTAL PCF = 0.25+2.00+0.50+1.50 = 4.25
TOTAL DAM = 0.50+2.00+0.50+2.00 = 5.00
TOTAL = 8.40+7.36+8.50+6.00+5.75+4.25+5.00 = 45.26 ≈46
 The estimated effort is 46 person-months.
 Based on an average burdened labor rate of $8,000 per month (Average labor rates (i.e.,
cost/unit effort)
 The total estimated project cost is = TOTAL estimated effort * Average labor rate
= 46*8000 = $368,000
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 95
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
Empirical estimation mode
The empirical data that support most estimation models are derived from a limited
sample of projects. For this reason, no estimation model is appropriate for all classes of software
and in all development environments. Therefore, you should use the results obtained from such
models judiciously.
An estimation model should be calibrated to reflect local conditions. The model should
be tested by applying data collected from completed projects, plugging the data into the model,
and then comparing actual to predicted results. If agreement is poor, the model must be tuned
and retested before it can be used.
The Structure of Estimation Models
A typical estimation model is derived using regression analysis on data collected from
past software projects. The overall structure of such models takes the form
Where A, B, and C are empirically derived constants, E is effort in person-months, and ev is the
estimation variable (either LOC or FP). The majority of estimation models have some form of
project adjustment component that enables E to be adjusted by other project characteristics (e.g.,
problem complexity, staff experience, development environment). Among the many LOC-
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 96
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
oriented estimation models proposed in the literature are
Cost Estimation
 Approximate judgement of the costs for a project. It should be done throughout the entire
life cycle.
 Why we need?
 To determine how much effort and time a software project requires.
 Important for making good management decisions.
 It facilitates competitive contract bids.
 It affect the planning and budgeting of a project.
Development Mode of S/W Projects
Mode
Organic
Semi
Detached
Embedded
Project
Size
Typically
2-50 KLOC
Typically
50300KLOC
Typically
over
300KLOC
Nature of
Project
Small size
project,
Experienced
developers.
Medium size
project and
team.
Large project,
Real-time
systems
Innovation
Deadline
Little
Not Tight
Medium
Medium
Significant
Tight
Constructive Cost Model(COCOMO )
 The COCOMO model is a single variable software cost estimation model developed by
Barry Boehm in 1981.
 The model uses a basic regression formula, with parameters that are derived from
historical project data and current project characteristics.
Hierarchy of Cocomo Model
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 97
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
1. Basic COCOMO model
2. Intermediate COCOMO model
3. Detailed COCOMO model
Basic COCOMO Model
 It take the form:
Effort(E) = ab * (KLOC)bb(in Person-months)
DevelopmentTime(D) = cb * (E) db (in month)
Average staff size(SS) = E/D (in Person)
Productivity(P) = KLOC / E (in KLOC/Person-month)
Project
Organic
Semidetached
Embedded
ab
2.4
3.0
3.6
bb
1.05
1.12
1.20
cb
2.5
2.5
2.5
db
0.38
0.35
0.32
Example
 A project size of 200KLOC is to be developed.S/W development team has average
experience on similar type of projects.The project schedule is not very
tight.Calculate the effort and development time of the project.
Ans: 200 KLOC implies semi-detached mode.
Hence, E= 3.0 * (200)1.12 = 1133.12 PM
D=2.5 * (1133.12)0.35 = 29.3 M
Avg. staff size(SS) = E/D
= 1133.12/29.3=38.67 Persons.
Productivity (P) = KLOC/E
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 98
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
= 200/1133.12=0.1765 KLOC/PM
Intermediate COCOMO
 Extension of Basic COCOMO
 Why Use ?
Basic model lacks accuracy
 Computes software development effort as a function of program size and set of 15 Cost
Drivers
 Cost Driver: A multiplicative factor that determines the effort required to complete the
software project.
 Why Cost Drivers?
Adjust the nominal cost of a project to the actual project Environment.
 For each Characteristics, Estimator decides the scale factor
Cost Drivers
• Personnel Factors
– Applications experience
– Programming language experience
– Virtual machine experience
– Personnel capability
– Personnel experience
– Personnel continuity
– Platform experience
– Language and tool experience
• Product Factors
– Required software reliability
– Database size
– Software product complexity
– Required reusability
– Documentation match to life cycle needs
– Product reliability and complexity
• Platform Factors
– Execution time constraint
– Main storage constraint
– Computer turn-around time
– Virtual machine volatility
– Platform volatility
– Platform difficulty
• Project Factors
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 99
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
– Use of software tools
– Use of modern programming practices
– Required development schedule
– Classified security application
– Multi-site development
– Requirements volatility
The calculation is done as follows
 Multiply all 15 Cost Drivers to get Effort Adjustment Factor(EAF)
 E(Effort) = ab(KLOC)bb * EAF(in Person-Month)
 D(Development Time) = cb(E)db (in month)
 SS (Avg Staff Size) = E/D (in persons)
 P (Productivity) = KLOC/E (in KLOC/Person-month)
Project
ab
bb
cb
db
Organic
3.2 1.05 2.5 0.38
Semidetached 3.0 1.12 2.5 0.35
Embedded
2.8 1.20 2.5 0.32
Example
A new project with estimated 400 KLOC embedded system has to be developed. Project
manager hires developers of low quality but a lot of experience in programming language.
Calculate the Effort, Development time, Staff size & Productivity.
Cost
Very Low Nominal High Very Extra
Drivers Low
High High
AEXP
1.29 1.13 1.00
0.91 0.82 -LEXP
1.14
1.07 1.00
0.95
--
--
EAF = 1.29 * 0.95 = 1.22
400 LOC implies Embedded System
Effort = 2.8*(400)1.20 * 1.225 = 3712 * 1.22 = 4528 person-months
Development Time = 2.5 * (4528)0.32 = 2.5 * 14.78 = 36.9 months
Avg. Staff Size = E/D = 4528/36.9 = 122 persons
Productivity = KLOC/Effort = 400/4528 = 0.0884 KLOC/person-month
Detailed COCOMO
 Detailed COCOMO = Intermediate COCOMO +assessment of Cost Drivers impact
on each phase.
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 100
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
 Phases
1) Plans and requirements
2) System Design
3) Detailed Design
4) Module code and test
5) Integrate and test
• Cost of each subsystem is estimated separately. This reduces the margin of error.
The Calculation
 Multiply all 15 Cost Drivers to get Effort Adjustment Factor(EAF)
 E(Effort) = ab(KLOC)bb * EAF(in Person-Month)
 D(Development Time) = cb(E)db (in month)
 Ep (Total Effort) = µp * E (in Person-Month)
 Dp (Total Development Time) = τp * D (in month)
Example
Consider a project to develop a full screen editor. The major components identified and their
sizes are (i) Screen Edit – 4K (ii) Command Lang Interpreter – 2K (iii) File Input and Output –
1K (iv) Cursor movement – 2K (v) Screen Movement – 3K. Assume the Required software
reliability is high, product complexity is high, analyst capability is high & programming
language experience is low. Use COCOMO model to estimate cost and time for different phases.
Size of modules : 4 + 2 + 1 + 2 + 3 = 13 KLOC [Organic]
Cost
Very Low Nominal High Very Extra
Drivers Low
High High
RELY
0.75 0.88 1.00
1.15 1.40 -CPLX
0.70
0.85 1.00
1.15
1.30
ACAP
1.46
1.19 1.00
0.86
0.71
LEXP
1.14
1.07 1.00
0.95
--
1.65
--
EAF = 1.15 * 1.15 * 0.86 * 1.07 = 1.2169
Initial Effort (E) = ab(KLOC)bb * EAF = 3.2*(12)1.05 * 1.2169
= 52.9 person-months
Initial Development Time = cb(E)db =2.5*(52.9)0.38 = 11.29 months
Phase value of µp and τp
Organic Small µp
Organic Small τp
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Plan &
Reqr
System
Design
Detail
Design
0.06
0.10
0.16
0.19
0.26
0.24
Module
code &
test
0.42
0.39
Integrati
on &
Test
0.16
0.18
Page 101
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
Phase wise effort & development time distribution
E
D
Dp (in months)
11.29
Ep (in personmonths)
0.06*52.9 = 3.17
Plan &
Requirement
System Design
52.9
52.9
11.29
0.16*52.9=8.46
0.19*11.29=2.14
Detail Design
52.9
11.29
0.26*52.9=13.74
0.24*11.29=2.70
Module code &
test
Integration &
test
52.9
11.29
0.42*52.9=22.21
0.39*11.29=4.40
52.9
11.29
0.16*52.9=8.46
0.18*11.29=2.03
0.10*11.29=1.12
22. Explain the Risk Management in detail
Definition of Risk
• A risk is a potential problem – it might happen and it might not
• Conceptual definition of risk
– Risk concerns future happenings
– Risk involves change in mind, opinion, actions, places, etc.
– Risk involves choice and the uncertainty that choice entails
• Two characteristics of risk
– Uncertainty – the risk may or may not happen, that is, there are no 100% risks
(those, instead, are called constraints)
– Loss – the risk becomes a reality and unwanted consequences or losses occur
•
•
•
•
Risk Categorization – Approach #1
Project risks
– They threaten the project plan
– If they become real, it is likely that the project schedule will slip and that costs
will increase
Technical risks
– They threaten the quality and timeliness of the software to be produced
– If they become real, implementation may become difficult or impossible
Business risks
– They threaten the viability of the software to be built
– If they become real, they jeopardize the project or the product
Sub-categories of Business risks
– Market risk – building an excellent product or system that no one really wants
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 102
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
–
–
–
–
Strategic risk – building a product that no longer fits into the overall business
strategy for the company
Sales risk – building a product that the sales force doesn't understand how to sell
Management risk – losing the support of senior management due to a change in
focus or a change in people
Budget risk – losing budgetary or personnel commitment
Risk Categorization – Approach #2
• Known risks
– Those risks that can be uncovered after careful evaluation of the project plan, the
business and technical environment in which the project is being developed, and
other reliable information sources (e.g., unrealistic delivery date)
• Predictable risks
– Those risks that are extrapolated from past project experience (e.g., past turnover)
• Unpredictable risks
– Those risks that can and do occur, but are extremely difficult to identify in
advance
Reactive vs. Proactive Risk Strategies
• Reactive risk strategies
– The majority of software teams and managers rely on this approach
– Nothing is done about risks until something goes wrong
• The team then flies into action in an attempt to correct the problem rapidly
(fire fighting)
– Crisis management is the choice of management techniques
• Proactive risk strategies
– Steps for risk management are followed
– Primary objective is to avoid risk and to have a contingency plan in place to
handle unavoidable risks in a controlled and effective manner
Steps for Risk Management
1) Identify possible risks; recognize what can go wrong
2) Analyze each risk to estimate the probability that it will occur and the impact (i.e.,
damage) that it will do if it does occur
3) Rank the risks by probability and impact
- Impact may be negligible, marginal, critical, and catastrophic
4) Develop a contingency plan to manage those risks having high probability and high
impact
Risk Identification
Risk identification is a systematic attempt to specify threats to the project plan
By identifying known and predictable risks, the project manager takes a first step toward
avoiding them when possible and controlling them when necessary
• Generic risks
•
•
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 103
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
•
– Risks that are a potential threat to every software project
Product-specific risks
– Risks that can be identified only by those a with a clear understanding of the
technology, the people, and the environment that is specific to the software that is
to be built
– This requires examination of the project plan and the statement of scope
Risk Item Checklist
• Used as one way to identify risks
• Focuses on known and predictable risks in specific subcategories (see next slide)
• Can be organized in several ways
– A list of characteristics relevant to each risk subcategory
– Questionnaire that leads to an estimate on the impact of each risk
– A list containing a set of risk component and drivers and their probability of
occurrence
Known and Predictable Risk Categories
• Product size – risks associated with overall size of the software to be built
• Business impact – risks associated with constraints imposed by management or the
marketplace
• Customer characteristics – risks associated with sophistication of the customer and the
developer's ability to communicate with the customer in a timely manner
• Process definition – risks associated with the degree to which the software process has
been defined and is followed
• Development environment – risks associated with availability and quality of the tools to
be used to build the project
• Technology to be built – risks associated with complexity of the system to be built and
the "newness" of the technology in the system
• Staff size and experience – risks associated with overall technical and project experience
of the software engineers who will do the work
Questionnaire on Project Risk
1) Have top software and customer managers formally committed to support the project?
2) Are end-users enthusiastically committed to the project and the system/product to be
built?
3) Are requirements fully understood by the software engineering team and its customers?
4) Have customers been involved fully in the definition of requirements?
5) Do end-users have realistic expectations?
6) Is the project scope stable?
7) Does the software engineering team have the right mix of skills?
8) Are project requirements stable?
9) Does the project team have experience with the technology to be implemented?
10) Is the number of people on the project team adequate to do the job?
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 104
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
11) Do all customer/user constituencies agree on the importance of the project and on the
requirements for the system/product to be built?
Risk Components and Drivers
•
•
•
The project manager identifies the risk drivers that affect the following risk components
– Performance risk - the degree of uncertainty that the product will meet its
requirements and be fit for its intended use
– Cost risk - the degree of uncertainty that the project budget will be maintained
– Support risk - the degree of uncertainty that the resultant software will be easy to
correct, adapt, and enhance
– Schedule risk - the degree of uncertainty that the project schedule will be
maintained and that the product will be delivered on time
The impact of each risk driver on the risk component is divided into one of four impact
levels
– Negligible, marginal, critical, and catastrophic
Risk drivers can be assessed as impossible, improbable, probable, and frequent
Risk Projection (Estimation)
•
Risk projection (or estimation) attempts to rate each risk in two ways
– The probability that the risk is real
– The consequence of the problems associated with the risk, should it occur
• The project planner, managers, and technical staff perform four risk projection steps (see
next slide)
• The intent of these steps is to consider risks in a manner that leads to prioritization
• Be prioritizing risks, the software team can allocate limited resources where they will
have the most impact
Risk Projection/Estimation Steps
1)
2)
3)
4)
Establish a scale that reflects the perceived likelihood of a risk (e.g., 1-low, 10-high)
Delineate the consequences of the risk
Estimate the impact of the risk on the project and product
Note the overall accuracy of the risk projection so that there will be no misunderstandings
Contents of a Risk Table
•
•
A risk table provides a project manager with a simple technique for risk projection
It consists of five columns
– Risk Summary – short description of the risk
– Risk Category – one of seven risk categories (slide 12)
– Probability – estimation of risk occurrence based on group input
– Impact – (1) catastrophic (2) critical (3) marginal (4) negligible
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 105
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
–
RMMM – Pointer to a paragraph in the Risk Mitigation, Monitoring, and
Management Plan
Risk
Summary
Risk
Category
Probability
Impact
(1-4)
RMMM
Developing a Risk Table
• List all risks in the first column (by way of the help of the risk item checklists)
• Mark the category of each risk
• Estimate the probability of each risk occurring
• Assess the impact of each risk based on an averaging of the four risk components to
determine an overall impact value
• Sort the rows by probability and impact in descending order
• Draw a horizontal cutoff line in the table that indicates the risks that will be given further
attention
Assessing Risk Impact
• Three factors affect the consequences that are likely if a risk does occur
– Its nature – This indicates the problems that are likely if the risk occurs
– Its scope – This combines the severity of the risk (how serious was it) with its
overall distribution (how much was affected)
– Its timing – This considers when and for how long the impact will be felt
• The overall risk exposure formula is
RE = P x C
– P = the probability of occurrence for a risk
– C = the cost to the project should the risk actually occur
• Example
– P = 80% probability that 18 of 60 software components will have to be developed
– C = Total cost of developing 18 components is $25,000
– RE = .80 x $25,000 = $20,000
Risk Mitigation, Monitoring, and Management
•
•
An effective strategy for dealing with risk must consider three issues
(Note: these are not mutually exclusive)
– Risk mitigation (i.e., avoidance)
– Risk monitoring
– Risk management and contingency planning
Risk mitigation (avoidance) is the primary strategy and is achieved through a plan
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 106
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
– Example: Risk of high staff turnover
Strategy for Reducing Staff Turnover
 Meet with current staff to determine causes for turnover (e.g., poor working conditions,
low pay, competitive job market)
 Mitigate those causes that are under our control before the project starts
 Once the project commences, assume turnover will occur and develop techniques to
ensure continuity when people leave
 Organize project teams so that information about each development activity is widely
dispersed
 Define documentation standards and establish mechanisms to ensure that documents are
developed in a timely manner
 Conduct peer reviews of all work (so that more than one person is "up to speed")
 Assign a backup staff member for every critical technologist
 During risk monitoring, the project manager monitors factors that may provide an
indication of whether a risk is becoming more or less likely
 Risk management and contingency planning assume that mitigation efforts have failed
and that the risk has become a reality
 RMMM steps incur additional project cost
 Large projects may have identified 30 – 40 risks
 Risk is not limited to the software project itself
 Risks can occur after the software has been delivered to the user
 Software safety and hazard analysis
 These are software quality assurance activities that focus on the identification and
assessment of potential hazards that may affect software negatively and cause an entire
system to fail
 If hazards can be identified early in the software process, software design features can be
specified that will either eliminate or control potential hazards
The RMMM Plan
• The RMMM plan may be a part of the software development plan (Paragraph 5.19.1) or
may be a separate document
• Once RMMM has been documented and the project has begun, the risk mitigation, and
monitoring steps begin
– Risk mitigation is a problem avoidance activity
– Risk monitoring is a project tracking activity
• Risk monitoring has three objectives
– To assess whether predicted risks do, in fact, occur
– To ensure that risk aversion steps defined for the risk are being properly applied
– To collect information that can be used for future risk analysis
• The findings from risk monitoring may allow the project manager to ascertain what risks
caused which problems throughout the project
Seven Principles of Risk Management
• Maintain a global perspective
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 107
YEAR/SEMESTER : II/IV SUB/CODE: CS6403 SOFTWARE ENGINEERING
UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT
–
•
•
•
•
•
•
•
View software risks within the context of a system and the business problem that
is is intended to solve
Take a forward-looking view
– Think about risks that may arise in the future; establish contingency plans
Encourage open communication
– Encourage all stakeholders and users to point out risks at any time
Integrate risk management
– Integrate the consideration of risk into the software process
Emphasize a continuous process of risk management
– Modify identified risks as more becomes known and add new risks as better
insight is achieved
Develop a shared product vision
– A shared vision by all stakeholders facilitates better risk identification and
assessment
Encourage teamwork when managing risk
– Pool the skills and experience of all stakeholders when conducting risk
management activities
However, the time spent in risk management results in
– Less disturbance during the project
– A greater ability to track and control a project
– The confidence that comes with planning for problems before they occur
– Risk management can absorb a significant amount of the project planning effort
Recording Risk Information
Project: Embedded software for XYZ system
Risk type: schedule risk
Priority (1 low ... 5 critical): 4
Risk factor: Project completion will depend on tests which require hardware component
under development. Hardware component delivery may be delayed
Probability: 60 %
Impact: Project completion will be delayed for each day that hardware is unavailable for
use in software testing
Monitoring approach:
Scheduled milestone reviews with hardware group
Contingency plan:
Modification of testing strategy to accommodate delay using software simulation
Estimated resources: 6 additional person months beginning in July
PREPARED BY
DR.S.PADMAPRIYA
DEPT. OF IT
Page 108