SE UNIT-1 Afroze Begum (ASST. PROF.

)CSE DCET

SOFTWARE ENGINEERING

UNIT -1

1. The Software Problem

1.1 Cost, Schedule, and Quality
1.2 Scale and Change
2. Software Processes
2.1 Process and Project
2.2 Component Software Processes
2.3 Software Development Process Models
2.3.1 Waterfall Model
2.3.2 Prototyping
2.3.3 Iterative Development
2.3.4 Rational Unified Process
2.3.5 Timeboxing Model
2.3.6 Extreme Programming and Agile Processes
2.3.7 Using Process Models in a Project
2.4 Project Management Process

2.3.3 Iterative Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3.4 Rational Unified Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3.5 Timeboxing Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 1
2.3.6 Extreme Programming and Agile Processes . . . . . . . . . . . . 28
2.3.7 Using Process Models in a Project . . . . . . . . . . . . . . . . . . . . 30
2.4 Project Management Process
 SE UNIT-1 Afroze Begum (ASST. PROF.)CSE DCET

ENGINEERING
Engineering is the application of scientific and practical knowledge to Invent, Design,Build, Maintain and
Improve Frameworks, processes etc.

SOFTWARE

It is defined as instructions that when executed provide desired features, function and performance. It is
a part of a computer system that consists of data or computer instructions. Software is often divided
into application software (programs that perform specific task) and system software (program that is
designed to run a computer's hardware which includes operating system and application programs).
Software is designed and built by software engineers and used by virtually everyone in society.
Software users are only concerned with whether or not software products meet their expectations and
make their tasks easier to complete.
Software has characteristics that are considerably different than those of hardware:
• Software is developed or engineered (logical); it is not manufactured (physical) in the classical
sense.
• Software doesn’t “wear out”.
• Although the industry is moving toward component-based construction, most software
continues to be custom built.

Today, seven broad categories of computer software present continuing challenges for software
engineers:
• System software: a collection of programs written to service other programs.
• Application software: stand-alone programs that solve a specific business need.
• Engineering/scientific software: used for scientific purposes and has been characterized by
“number crunching” algorithms.
• Embedded software—resides within a product or system and is used to implement and control
features and functions for the end user and for the system itself.
• Product-line software—designed to provide a specific capability for use by many different
customers.
• Web applications—called “WebApps” a set of linked hypertext files that present information
using text and limited graphics.
• Artificial intelligence software—makes use of nonnumeric algorithms to solve complex
problems that are not open to computation or straight forward analysis

Legacy Software: Some of the software is just released to individuals, industry, and government, but
other programs are older and are referred to as legacy software. Legacy software systems were
developed decades ago and have been continually modified to meet changes in business requirements
and computing platforms. Legacy software is characterized by longevity and business criticality.
Unfortunately, there is sometimes one additional characteristic that is present in legacy software—poor
quality. However, as time passes, legacy systems often evolve for one or more of the following
reasons:

• The software must be adapted to meet the needs of new computing environments or technology.
• The software must be enhanced to implement new business requirements.
2
SE UNIT-1 Afroze Begum (ASST. PROF.)CSE DCET

• The software must be extended to make it interoperable with other more modern systems or
databases.
• The software must be re-architected to make it viable within a network environment.
In order to build software that is ready to meet the challenges the following things are to be taken into
consideration:
1. Understand the problem before a software solution is developed.
2. Design becomes a crucial activity.
3. Software should exhibit high quality.
4. Software should be maintainable.
This leads to the conclusion that software in all of its forms and across all of its application domains
should be engineered, thereby leading to Software Engineering.

SOFTWARE ENGINEERING

Software engineering is the systematic application of engineering approaches to the development of

software. A software engineer is a person who applies the principles of software engineering to design,
develop, maintain, test, and evaluate computer software.
It can also be defined as “the application of a systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software”.

Software engineering is a Layered Technology

Software engineering encompasses a process, management techniques, technical methods, and the use
of tools.
• The bedrock that supports software engineering is a quality focus.
• The foundation for software engineering is the process layer that holds the technology layers
together and enables the timely development of computer software. The software process forms
the basis for management control of software projects and establishes the context in which
technical methods are applied, work products (models, documents, data, reports, forms, etc.) are
produced, milestones are established, quality is ensured, and change is properly managed.
• Software engineering methods provide the technical how-to’s for building software. Software
engineering methods rely on a set of basic principles that govern each area of the technology
and include modeling activities and other descriptive techniques.
• Software engineering tools provide automated or semi automated support for the process and
the methods. When tools are integrated the information created by one tool can be used by
another, a system for the support of software development, called computer-aided software
engineering, is established.

3
SE UNIT-1 Afroze Begum (ASST. PROF.)CSE DCET

1.The Software Problem

1.1 Cost, Schedule, and Quality
Though the need for high quality distinguishes industrial strength software from others, cost and schedule
are other major driving forces for such software. In the industrial-strength software domain, there are
three basic forces at play—cost, schedule, and quality. The software should be produced at reasonable
cost, in a reasonable time, and should be of good quality. These three parameters often drive and define a
software project.
Industrial-strength software is very expensive primarily due to the fact that software development is
extremely labor-intensive. To get an idea of the costs involved, let us consider the current state of practice
in the industry. Lines of code (LOC) or thousands of lines of code (KLOC) delivered is by far the most
commonly used measure of software size in the industry. As the main cost of producing software is the
manpower employed, the cost of developing software is generally measured in terms of person-months of
effort spent in development. And productivity is frequently measured in the industry in terms of LOC (or
KLOC) per person-month.
The productivity in the software industry for writing fresh code generally ranges from few hundred to
about 1000+ LOC per person-month. This productivity is over the entire development cycle, not just the
coding task. Software companies often charge the client for whom they are developing the software
between $3000 - $15,000 per person-month. With a productivity of 1000 LOC per person-month, it
means that each line of delivered code costs between $3 and $15! And even small projects can easily end
up with software of 50,000 LOC. With this productivity, such a software project will cost between
$150,000 and $750,000!
Schedule is another important factor in many projects. Business trends are dictating that the time to
market of a product should be reduced; that is, the cycle time from concept to delivery should be small.
For software this means that it needs to be developed faster, and within the specified time. Unfortunately,
the history of software is full of cases where projects have been substantially late.
Clearly, therefore, reducing the cost and the cycle time for software development are central goals of
software engineering. Productivity in terms of output (KLOC) per person-month can adequately capture
both cost and schedule concerns. If productivity is higher, it should be clear that the cost in terms of
person-months will be lower (the same work can now be done with fewer person-months). Similarly, if
productivity is higher, the potential of developing the software in less time improves—a team of higher
productivity will finish a job in less time than a same-size team with lower productivity. (The actual time
the project will take, of course, depends also on the number of people allocated to the project.) Hence,
pursuit of higher productivity is a basic driving force behind software engineering and a major reason for
using the different tools and techniques.
Besides cost and schedule, the other major factor driving software engineering is quality. Today, quality
is one of the main mantras, and business strategies are designed around it. Unfortunately, a large number
of instances have occurred regarding the unreliability of software—the software often does not do what it
is supposed to do or does something it is not supposed to do. Clearly, developing high-quality software is
another fundamental goal of software engineering. However, while cost is generally well understood, the
concept of quality in the context of software needs further elaboration.
The international standard on software product quality suggests that

4
SE UNIT-1 Afroze Begum (ASST. PROF.)CSE DCET

software quality comprises six main attributes, as shown in Figure 1.1. These attributes can be defined as
follows:
– Functionality. The capability to provide functions which meet stated and implied needs when the
software is used.
– Reliability. The capability to provide failure-free service.
– Usability. The capability to be understood, learned, and used.
– Efficiency. The capability to provide appropriate performance relative to the amount of resources used.
– Maintainability. The capability to be modified for purposes of making corrections, improvements, or
adaptation.
– Portability. The capability to be adapted for different specified environments without applying actions
or means other than those provided for this purpose in the product.
With multiple dimensions to quality, different projects may emphasize different attributes, and a global
single number for quality is not possible. However, despite the fact that there are many quality attributes,
reliability is generally accepted to be the main quality criterion. As unreliability of software is due to the
presence of defects in the software, one measure of quality is the number of defects in the delivered
software per unit size (generally taken to be thousands of lines of code, or KLOC). With this as the major
quality criterion, the quality objective is to reduce the number of defects per KLOC as much as possible.
Current best practices in software engineering have been able to reduce the defect density to less than 1
defect per KLOC.
To determine the quality of a software product, we need to determine the number of defects in the
software that was delivered. This number is clearly not known at delivery time and may never be known.
One approach to measure quality is to log the defects found in 6 months (or 1 year) after delivery and
define quality with respect to these defects. This means that quality of delivered software can only be
determined 6 months after its delivery. The defect density can, however, also be estimated from past data
of similar projects—if similar approaches are being used, then it is expected that the current project will
have similar defect density as the past projects.
It should be pointed out that to use this definition of quality, what a defect is must be clearly defined. A
defect could be some problem in the software that causes the software to crash or a problem that causes
an output to be not properly aligned or one that misspells some word, etc. The exact definition of what is
considered a defect will clearly depend on the project or the standards the organization developing the
project uses.
Besides reliability, another quality attribute of great interest is maintainability. Once the software is
delivered and deployed, it enters the maintenance phase. Why is maintenance needed for software, when
software has no physical components that can degrade with age? Software needs to be maintained
5
SE UNIT-1 Afroze Begum (ASST. PROF.)CSE DCET

because of the residual defects remaining in the system. It is commonly believed that the state of the art
today is limited and developing software with zero defect density is not possible. These defects, once
discovered, need to be removed, leading to what is called corrective maintenance. Maintenance is also
needed to change the delivered software to satisfy the enhanced needs of the users and the environment,
leading to adaptive maintenance. Over the life of a software system, maintenance cost can far exceed the
cost of original development. The maintenance-to-development-cost ratio has been variously suggested as
80:20, 70:30, or 60:40. Due to this high cost, maintainability attribute of delivered software is of high
interest—it is clearly desirable to have software systems that are easier to maintain.
1.2 Scale and Change
Though cost, schedule, and quality are the main driving forces for a project in our problem domain (of
industry strength software), there are some other characteristics of the problem domain that also influence
the solution approaches employed. We focus on two such characteristics—scale and change.
Most industrial-strength software systems tend to be large and complex, requiring tens of thousands of
lines of code. Sizes of some of the well-known software products are given in Table 1.1.
As can be expected, development of a large system requires a different set of methods compared to
developing a small system, as the methods that are used for developing small systems often do not scale
up to large systems. An example will illustrate this point. Consider the problem of counting people in a
room versus taking a census of a country. Both are essentially counting problems. But the methods used
for counting people in a room will just not work when taking a census. A different set of methods will
have to be used for conducting a census, and the census problem will require considerably more
management, organization, and validation, in addition to counting.

Similarly, methods that one can use to develop programs of a few hundred lines cannot be expected to
work when software of a few hundred thousand lines needs to be developed. A different set of methods
must be used for developing large software.
Any software project involves the use of engineering and project management. In small projects, informal
methods for development and management can be used. However, for large projects, both have to be
much more rigorous, as illustrated in Figure 1.2. In other words, to successfully execute a project, a
proper method for engineering the system has to be employed and the project has to be tightly managed to
make sure that cost, schedule, and quality are under control. Large scale is a key characteristic of the
problem domain and the solution approaches should employ tools and techniques that have the ability to
build large software systems.
Change is another characteristic of the problem domain which the approaches for development must
handle. As the complete set of requirements for the system is generally not known (often cannot be
6
SE UNIT-1 Afroze Begum (ASST. PROF.)CSE DCET

known at the start of the project) or stated, as development proceeds and time passes, additional
requirements are identified, which need to be incorporated in the software being developed. This need for
changes requires that methods for development embrace change and accommodate it efficiently. Change
requests can be quite disruptive to a project, and if not handled properly, can consume up to 30 to 40% of
the development cost.
As discussed above, software has to be changed even after it has been deployed. Though traditionally
changes in software during maintenance have been distinguished from changes that occur while the
development is taking place, these lines are blurring, as fundamentally the changes in both of these
scenarios are similar—existing source code needs to be changed due to some changes in the requirements
or due to some defects that need to be removed.

Fiq 2: The Problem of Scale

Overall, as the world changes faster, software has to change faster, even while under development.
Changes in requirements are therefore a characteristic of the problem domain. In today’s world,
approaches that cannot accept and accommodate change are of little use—they can solve only those few
problems that are change resistant.

7
SE UNIT-1 Afroze Begum (ASST. PROF.)CSE DCET

2. Software Processes
2.1 Process and Project
A process is a sequence of steps performed for a given purpose [52]. As mentioned earlier, while
developing (industrial strength) software, the purpose is to develop software to satisfy the needs of some
users or clients, as shown in Figure 2.1. A software project is one instance of this problem, and the
development process is what is used to achieve this purpose.

So, for a project its development process plays a key role—it is by following the process the desired end
goal of delivering the software is achieved. However, as discussed earlier, it is not sufficient to just reach
the final goal of having the desired software, but we want that the project be done at low cost and in low
cycle time, and deliver high-quality software. The role of process increases due to these additional goals,
and though many processes can achieve the basic goal of developing software in Figure 2.1, to achieve
high Q&P we need some “optimum” process. It is this goal that makes designing a process a challenge.
We must distinguish process specification or description from the process itself. A process is a dynamic
entity which captures the actions performed. Process specification, on the other hand, is a description of
process which presumably can be followed in some project to achieve the goal for which the process is
designed.
In a project, a process specification may be used as the process the project plans to follow. The actual
process is what is actually done in the project. Note that the actual process can be different from the
planned process, and ensuring that the specified process is being followed is a nontrivial problem.
However, in this book, we will assume that the planned and actual processes are the same and will not
distinguish between the two and will use the term process to refer to both.
A process model specifies a general process, which is “optimum” for a class of projects. That is, in the
situations for which the model is applicable, using the process model as the project’s process will lead to
the goal of developing software with high Q&P. A process model is essentially a compilation of best
practices into a “recipe” for success in the project. In other words, a process is a means to reach the goals
of high quality, low cost, and low cycle time, and a process model provides a process structure that is well
suited for a class of projects.
A process is often specified at a high level as a sequence of stages. The sequence of steps for a stage is
the process for that stage, and is often referred to as a subprocess of the process.

8
SE UNIT-1 Afroze Begum (ASST. PROF.)CSE DCET

2.2 Component Software Processes

As defined above, a process is the sequence of steps executed to achieve a goal. Since many different
goals may have to be satisfied while developing software, multiple processes are needed. Many of these
do not concern software engineering, though they do impact software development. These could be
considered nonsoftware process. Business processes, social processes, and training processes are all
examples of processes that come under this. These processes also affect the software development
activity but are beyond the purview of software engineering.
The processes that deal with the technical and management issues of software development are
collectively called the software process. As a software project will have to engineer a solution and
properly manage the project, there are clearly two major components in a software process—a
development process and a project management process. The development process specifies all the
engineering activities that need to be performed, whereas the management process specifies how to plan
and control these activities so that cost, schedule, quality, and other objectives are met. Effective
development and project management processes are the key to achieving the objectives of delivering the
desired software satisfying the user needs, while ensuring high productivity and quality.
During the project many products are produced which are typically composed of many items (for
example, the final source code may be composed of many source files). These items keep evolving as the
project proceeds, creating many versions on the way. As development processes generally do not focus
on evolution and changes, to handle them another process called software configuration control process is
often used. The objective of this component process is to primarily deal with managing change, so that
the integrity of the products is not violated despite changes.
These three constituent processes focus on the projects and the products and can be considered as
comprising the product engineering processes, as their main objective is to produce the desired product. If
the software process can be viewed as a static entity, then these three component processes will suffice.
However, a software process itself is a dynamic entity, as it must change to adapt to our increased
understanding about software development and availability of newer technologies and tools. Due to this, a
process to manage the software process is needed.
The basic objective of the process management process is to improve the software process. By
improvement, we mean that the capability of the process to produce quality goods at low cost is
improved. For this, the current software process is studied, frequently by studying the projects that have
been done using the process. The whole process of understanding the current process, analyzing its
properties, determining how to improve, and then affecting the improvement is dealt with by the process
management process.
The relationship between these major component processes is shown in Figure 2.2. These component
processes are distinct not only in the type of activities performed in them, but typically also in the people
who perform the activities specified by the process. In a typical project, development activities are
performed by programmers, designers, testers, etc.; the project management process activities are
performed by the project management; configuration control process activities are performed by a group
generally called the configuration controller; and the process management process activities are
performed by the software engineering process group (SEPG).

9
SE UNIT-1 Afroze Begum (ASST. PROF.)CSE DCET

Figure 2.2: Software processes

2.3 Software Development Process Models
For the software development process, the goal is to produce a high-quality software product. It therefore
focuses on activities directly related to production of the software, for example, design, coding, and
testing. As the development process specifies the major development and quality control activities that
need to be performed in the project, it forms the core of the software process. The management process is
often decided based on the development process.
A project’s development process defines the tasks the project should perform, and the order in which they
should be done. A process limits the degrees of freedom for a project by specifying what types of
activities must be undertaken and in what order, such that the “shortest” (or the most efficient) path is
obtained from the user needs to the software satisfying these needs. The process drives a project and
heavily influences the outcome.
As discussed earlier, a process model specifies a general process, usually as a set of stages in which a
project should be divided, the order in which the stages should be executed, and any other constraints and
conditions on the execution of stages. The basic premise behind a process model is that, in the situations
for which the model is applicable, using the process model as the project’s process will lead to low cost,
high quality, reduced cycle time, or provide other benefits. In other words, the process model provides
generic guidelines for developing a suitable process for a project.
Due to the importance of the development process, various models have been proposed. In this section we
will discuss some of the major models.

2.3.1 The Waterfall Model

The waterfall model, sometimes called the classic life cycle, suggests a systematic, sequential approach
to software development that begins with customer specification of requirements and progresses
through planning, modeling, construction, and deployment, culminating in ongoing support of the
completed software. In "The Waterfall" approach, the whole process of software development is
divided into separate phases and, the outcome of one phase acts as the input for the next phase
sequentially.

10
 SE UNIT-1 Afroze Begum (ASST. PROF.)CSE DCET

The sequential phases in Waterfall model are :

 Requirement Gathering and analysis: all possible requirements of the system to be developed
are captured in this phase and documented in a requirement specification document.
 System Design: the requirement specifications from first phase are studied in this phase and the
system design is prepared. This system design helps in specifying hardware and system
requirements and helps in defining the overall system architecture.
 Implementation: with inputs from the system design, the system is first developed in small
programs called units, which are integrated in the next phase. Each unit is developed and tested
for its functionality, which is referred to as Unit Testing.
 Integration and Testing: all the units developed in the implementation phase are integrated into
a system after testing of each unit. Post integration the entire system is tested for any faults and
failures.
 Deployment of system: once the functional and non-functional testing is done; the product is
deployed in the customer environment or released into the market.
 Maintenance: There are some issues which come up in the client environment. To fix those
issues, patches are released. Also to enhance the product some better versions are released.
Maintenance is done to deliver these changes in the customer environment.

All these phases are cascaded to each other in which progress is seen as flowing steadily downwards
(like a waterfall) through the phases. The next phase is started only after the defined set of goals are
achieved for previous phase and it is signed off, so the name "Waterfall Model". In this model, phases
do not overlap.
Advantages of Waterfall model

o This model is simple to implement also the number of resources that are required for it is minimal.
o The requirements are simple and explicitly declared; they remain unchanged during the entire
project development.
o The start and end points for each phase is fixed, which makes it easy to cover progress.
o The release date for the complete product, as well as its final cost, can be determined before
development.
o It gives easy to control and clarity for the customer due to a strict reporting system.

11
 SE UNIT-1 Afroze Begum (ASST. PROF.)CSE DCET

Disadvantages of Waterfall model

o In this model, the risk factor is higher, so this model is not suitable for more significant and complex
projects.
o This model cannot accept the changes in requirements during development.
o It becomes tough to go back to the phase. For example, if the application has now shifted to the
coding phase, and there is a change in requirement, It becomes tough to go back and change it.
o Since the testing done at a later stage, it does not allow identifying the challenges and risks in the
earlier phase, so the risk reduction strategy is difficult to prepare.

2.3.2 Prototyping Model

The prototype model requires that before carrying out the development of actual software, a working
prototype of the system should be built. A prototype usually turns out to be a very crude version of the
actual system, possible exhibiting limited functional capabilities, low reliability, and inefficient
performance as compared to actual software.

The different phases of Prototyping model are:

 Communication: In this phase, developer and customer meet and discuss the overall objectives
of the software.
 Quick Plan: Quick design is implemented when requirements are known. It includes only the
important aspects like input and output format of the software. It focuses on those aspects
which are visible to the user rather than the detailed plan. It helps to construct a prototype.
 Modeling Quick Design: This phase gives the clear idea about the development of software
because the software is now built. It allows the developer to better understand the exact
requirements.
 Construction of prototype: The prototype is evaluated by the customer itself.
 Deployment, delivery, feedback: If the user is not satisfied with current prototype then it refines
according to the requirements of the user. The process of refining the prototype is repeated until
all the requirements of users are met. When the users are satisfied with the developed prototype
then the system is developed on the basis of final prototype.

12
 SE UNIT-1 Afroze Begum (ASST. PROF.)CSE DCET

Advantages of Prototyping Model:

 Prototype model need not know the detailed input, output, processes, adaptability of operating
system and full machine interaction.
 In the development process of this model users are actively involved.
 The development process is the best platform to understand the system by the user.
 Errors are detected much earlier.
 Gives quick user feedback for better solutions.
 It identifies the missing functionality easily. It also identifies the confusing or difficult
functions.
Disadvantages of Prototyping Model:
 The client involvement is more and it is not always considered by the developer.
 It is a slow process because it takes more time for development.
 Many changes can disturb the rhythm of the development team.
 It is a thrown away prototype when the users are confused with it.

2.3.3 Iterative Development

In this Model, you can start with some of the software specifications and develop the first version of the
software. After the first version if there is a need to change the software, then a new version of the software
is created with a new iteration. Every release of the Iterative Model finishes in an exact and fixed period
that is called iteration.
The Iterative Model allows the accessing earlier phases, in which the variations made respectively. The final
output of the project renewed at the end of the Software Development Life Cycle (SDLC) process.



The various phases of Iterative model are as follows:

1. Requirement gathering & analysis: In this phase, requirements are gathered from customers and
check by an analyst whether requirements will fulfil or not. Analyst checks that need will achieve within
budget or not. After all of this, the software team skips to the next phase.

2.Design: In the design phase, team design the software by the different diagrams like Data Flow
diagram, activity diagram, class diagram, state transition diagram, etc.

13
SE UNIT-1 Afroze Begum (ASST. PROF.)CSE DCET

3. Implementation: In the implementation, requirements are written in the coding language and
transformed into computer programmes which are called Software.

4. Testing: After completing the coding phase, software testing starts using different test methods. There
are many test methods, but the most common are white box, black box, and grey box test methods.

5. Deployment: After completing all the phases, software is deployed to its work environment.

6. Review: In this phase, after the product deployment, review phase is performed to check the behaviour
and validity of the developed product. And if there are any error found then the process starts again from
the requirement gathering.

7. Maintenance: In the maintenance phase, after deployment of the software in the working environment
there may be some bugs, some errors or new updates are required. Maintenance involves debugging and
new addition options.

Figure 2.6: Iterative delivery approach.

When to use the Iterative Model?

1. When requirements are defined clearly and easy to understand.

2. When the software application is large.

3. When there is a requirement of changes in future.

Advantage(Pros) of Iterative Model:

1. Testing and debugging during smaller iteration is easy.

2. A Parallel development can plan.

14
 SE UNIT-1 Afroze Begum (ASST. PROF.)CSE DCET

3. It is easily acceptable to ever-changing needs of the project.

4. Risks are identified and resolved during iteration.

5. Limited time spent on documentation and extra time on designing.

Disadvantage(Cons) of Iterative Model:

1. It is not suitable for smaller projects.

2. More Resources may be required.

3. Design can be changed again and again because of imperfect requirements.

4. Requirement changes can cause over budget.

5. Project completion date not confirmed because of changing requirements.

2.3.4 The Rational Unified Process

Rational Unified Process (RUP) is another iterative process model that was designed by Rational, now part
of IBM. Though it is a general process model, it was designed for object-oriented development using the
Unified Modeling Language (UML).

RUP proposes that development of software be divided into cycles, each cycle delivering a fully working
system. Generally, each cycle is executed as a separate project whose goal is to deliver some additional
capability to an existing system (built by the previous cycle). Hence, for a project, the process for a cycle
forms the overall process. Each cycle itself is broken into four consecutive phases:
– Inception phase
– Elaboration phase
– Construction phase
– Transition phase

15
SE UNIT-1 Afroze Begum (ASST. PROF.)CSE DCET

This process divides the development process into five phases:

 Inception
 Elaboration
 Conception
 Transition
 Production
The Inception phase of the UP encompasses both customer communication and planning activities.
By collaborating with stakeholders, business requirements for the software are identified; a rough
architecture for the system is proposed; and a plan for the iterative, incremental nature of the ensuing
project is developed.

The Elaboration phase encompasses the communication and modeling activities of the generic
process model. Elaboration refines and expands the preliminary use cases that were developed as part
of the inception phase and expands the architectural representation to include five different views of
the software the use case model, the requirements model, the design model, the implementation model,
and the deployment model. Elaboration creates an “executable architectural baseline” that represents a
“first cut” executable system.

The Conception phase of the UP is identical to the construction activity defined for the generic
software process. Using the architectural model as input, the construction phase develops or acquires
the software components that will make each use case operational for end users. To accomplish this,
requirements and design models that were started during the elaboration phase are completed to reflect
the final version of the software increment. All necessary and required features and functions for the
software increment (the release) are then implemented in source code.
The Transition phase of the UP encompasses the latter stages of the generic construction activity
and the first part of the generic deployment (delivery and feedback) activity. Software is given to end
users for beta testing and user feedback reports both defects and necessary changes. At the conclusion
of the transition phase, the software increment becomes a usable software release.

Figure 2.7: The RUP model.

16
SE UNIT-1 Afroze Begum (ASST. PROF.)CSE DCET

The Production phase of the UP coincides with the deployment activity of the generic process.
During this phase, the ongoing use of the software is monitored, support for the operating environment
(infrastructure) is provided, and defect reports and requests for changes are submitted and evaluated. It
is likely that at the same time the construction, transition, and production phases are being conducted,
work may have already begun on the next software increment. This means that the five UP phases do
not occur in a sequence, but rather with staggered concurrency.

Overall, RUP provides a flexible process model, which follows an iterative approach not only at a top
level (through cycles), but also encourages iterative approach during each of the phases in a cycle. And in
phases, it allows the different tasks to be done as per the needs of the project.

Advantages:

1. It provides good documentation, it completes the process in itself.

2. It provides risk-management support.

3. It reuses the components, and hence total time duration is less.

4. Good online support is available in the form of tutorials and training.

Disadvantages:

1. Team of expert professional is required, as the process is complex.

2. Complex and not properly organized process.

3. More dependency on risk management.

4. Hard to integrate again and again.

17
SE UNIT-1 Afroze Begum (ASST. PROF.)CSE DCET

2.3.5 Timeboxing Model

To speed up development, parallelism between the different iterations can be employed. That is, a new
iteration commences before the system produced by the current iteration is released, and hence
development of a new release happens in parallel with the development of the current release. By starting
an iteration before the previous iteration has completed, it is possible to reduce the average delivery time
for iterations. However, to support parallel execution, each iteration has to be structured properly and
teams have to be organized suitably. The timeboxing model proposes an approach for these.

In the timeboxing model, the basic unit of development is a time box, which is of fixed duration. Since
the duration is fixed, a key factor in selecting the requirements or features to be built in a time box is what
can be fit into the time box. This is in contrast to regular iterative approaches where the functionality is
selected and then the time to deliver is determined. Timeboxing changes the perspective of development
and makes the schedule a nonnegotiable and a high-priority commitment.

Each time box is divided into a sequence of stages, like in the waterfall model. Each stage performs some
clearly defined task for the iteration and produces a clearly defined output. The model also requires that
the duration of each stage, that is, the time it takes to complete the task of that stage, is approximately the
same. Furthermore, the model requires that there be a dedicated team for each stage. That is, the team for
a stage performs only tasks of that stage—tasks for other stages are performed by their respective teams.
This is quite different from other iterative models where the implicit assumption is that the same team
performs all the different tasks of the project or the iteration.

Having time-boxed iterations with stages of equal duration and having dedicated teams renders itself to
pipelining of different iterations. (Pipelining is a concept from hardware in which different instructions
are executed in parallel, with the execution of a new instruction starting once the first stage of the
previous instruction is finished.)

To illustrate the use of this model, consider a time box consisting of three stages: requirement
specification, build, and deployment. The requirement stage is executed by its team of analysts and ends
with a prioritized list of requirements to be built in this iteration along with a high-level design. The build
team develops the code for implementing the requirements, and performs the testing. The tested code is
then handed over to the deployment team, which performs predeployment tests, and then installs the
system for production use. These three stages are such that they can be done in approximately equal time
in an iteration.

With a time box of three stages, the project proceeds as follows. When the requirements team has finished
requirements for timebox-1, the requirements are given to the build team for building the software. The
requirements team then goes on and starts preparing the requirements for timebox-2. When the build for
timebox-1 is completed, the code is handed over to the deployment team, and the build team moves on to
build code for requirements for timebox- 2, and the requirements team moves on to doing requirements
for timebox-3. This pipelined execution of the timeboxing process is shown in Figure2.8

18
SE UNIT-1 Afroze Begum (ASST. PROF.)CSE DCET

Figure 2.8: Executing the timeboxing process model.

With a three-stage time box, at most three iterations can be concurrently in progress. If the time box is of
size T days, then the first software delivery will occur after T days. The subsequent deliveries, however,
will take place after every T/3 days. For example, if the time box duration T is 9 weeks (and each stage
duration is 3 weeks), the first delivery is made 9 weeks after the start of the project. The second delivery
is made after 12 weeks, the third after 15 weeks, and so on. Contrast this with a linear execution of
iterations, in which the first delivery will be made after 9 weeks, the second after 18 weeks, the third after
27 weeks, and so on.

There are three teams working on the project—the requirements team, the build team, and the deployment
team. The teamwise activity for the 3-stage pipeline discussed above is shown in Figure 2.9

It should be clear that the duration of each iteration has not been reduced.

Figure 2.9: Tasks of different teams.

The total work done in a time box and the effort spent in it also remains the same—the same amount of
software is delivered at the end of each iteration as the time box undergoes the same stages. If the effort
and time spent in each iteration also remains the same, then what is the cost of reducing the delivery
time? The real cost of this reduced time is in the resources used in this model. With timeboxing, there are
dedicated teams for different stages and the total team size for the project is the sum of teams of different
19
SE UNIT-1 Afroze Begum (ASST. PROF.)CSE DCET

stages. This is the main difference from the situation where there is a single team which performs all the
stages and the entire team works on the same iteration.

Hence, the timeboxing provides an approach for utilizing additional manpower to reduce the delivery
time. It is well known that with standard methods of executing projects, we cannot compress the cycle
time of a project substantially by adding more manpower. However, through the timeboxing model, we
can use more manpower in a manner such that by parallel execution of different stages we are able to
deliver software quicker. In other words, it provides a way of shortening delivery times through the use of
additional manpower.

Timeboxing is well suited for projects that require a large number of features to be developed in a short
time around a stable architecture using stable technologies. These features should be such that there is
some flexibility in grouping them for building a meaningful system in an iteration that provides value to
the users. The main cost of this model is the increased complexity of project management (and managing
the products being developed) as multiple developments are concurrently active. Also, the impact of
unusual situations in an iteration can be quite disruptive.

Advantages

1. Speeds up the development process and shortens the delivery time

2. Well suited to develop projects with a number of features in short time period.

Disadvantages

1. Project management becomes more complex.

2. Not suited to projects in which entire development work cannot be divided into multiple iterations of
almost, equal duration.

2.3.6 Agile Development

Agile software engineering represents a reasonable compromise between to conventional software
engineering for certain classes of software and certain types of software projects. Agile processes can
deliver successful systems quickly. It stresses on continuous communication and collaboration among
developers and customers.

WHAT IS AGILITY?

Agile software engineering embraces a philosophy that encourages customer satisfaction, incremental
software delivery, small project teams (composed of software engineers and stakeholders), informal
methods, and minimal software engineering work products. Agile software engineering guidelines
stress on-time delivery of an operational software increment over analysis and design.
 An agile team is able to respond to changes during project development.
 Agile development recognizes that project plans must be flexible.
 Agility encourages team structures and attitudes that make communication among developers
and customers more facile.
 Agility eliminates the separation between customers and developers.
20
SE UNIT-1 Afroze Begum (ASST. PROF.)CSE DCET

 Agility emphasizes the importance of rapid delivery of operational software and de-emphasizes
importance of intermediate work products.
 Agility can be applied to any software process as long as the project team is allowed to
streamline tasks and conduct planning in way that eliminate non-essential work products.

AGILITY AND THE COST OF CHANGE

In software development the cost of change increases nonlinearly as a project progresses. It is relatively
easy to accommodate a change when a software team is early in a project. Costs escalate quickly, and
the time and cost required to ensure that the change is made without unintended side effects is
nontrivial.An agile process reduces the cost of change because software is released in increments and
change can be better controlled within an increment .
Agility is dynamic, content specific, aggressively change embracing and growth oriented.

21
 SE UNIT-1 Afroze Begum (ASST. PROF.)CSE DCET

WHAT IS AN AGILE PROCESS?

The meaning of Agile is swift or versatile."Agile process model" refers to a software development
approach based on iterative development. Agile methods break tasks into smaller iterations, or parts do not
directly involve long term planning. The project scope and requirements are laid down at the beginning of
the development process. Plans regarding the number of iterations, the duration and the scope of each
iteration are clearly defined in advance.
Each iteration is considered as a short time "frame" in the Agile process model, which typically lasts from
one to four weeks. The division of the entire project into smaller parts helps to minimize the project risk and
to reduce the overall project delivery time requirements. Each iteration involves a team working through a
full software development life cycle including planning, requirements analysis, design, coding, and testing
before a working product is demonstrated to the client.

Agility Principles:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable
software.
2. Welcome changing requirements, even late in development
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need,
and trust them to get the job done
6. The most efficient and effective method of conveying information to and within a development
team is face-to-face conversation
7. Working software is the primary measure of progress
8. Agile processes promote sustainable development. The sponsors, developers, and users should
be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility
10. Simplicity—the art of maximizing the amount of work not done—is essential
11. The best architectures, requirements, and designs emerge from self– organizing teams
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts
its behavior accordingly
Not every agile process model applies these 12 principles with equal weight, and some models choose
to ignore the importance of one or more of the principles. However, the principles define an agile spirit
that is maintained in each of the process models.

22
 SE UNIT-1 Afroze Begum (ASST. PROF.)CSE DCET

Phases of Agile Model:

1. Requirements gathering
2. Design the requirements
3. Construction/ iteration
4. Testing/ Quality assurance
5. Deployment
6. Feedback

1. Requirements gathering: In this phase, you must define the requirements. You should explain business
opportunities and plan the time and effort needed to build the project. Based on this information, you can
evaluate technical and economic feasibility.
2.Design the requirements: When you have identified the project, work with stakeholders to define
requirements. You can use the user flow diagram or the high-level UML diagram to show the work of new
features and show how it will apply to your existing system.
3. Construction/ iteration: When the team defines the requirements, the work begins. Designers and
developers start working on their project, which aims to deploy a working product. The product will
undergo various stages of improvement, so it includes simple, minimal functionality.
4. Testing: In this phase, the Quality Assurance team examines the product's performance and looks for the
bug.
5. Deployment: In this phase, the team issues a product for the user's work environment.
6. Feedback: After releasing the product, the last step is feedback. In this, the team receives feedback about
the product and works through the feedback.

Advantages of Agile model:

 Customer satisfaction by rapid, continuous delivery of useful software.

 People and interactions are emphasized rather than process and tools. Customers, developers and
testers constantly interact with each other.
 Working software is delivered frequently (weeks rather than months).
 Face-to-face conversation is the best form of communication.
 Close, daily cooperation between business people and developers.
 Continuous attention to technical excellence and good design.
 Regular adaptation to changing circumstances.
 Even late changes in requirements are welcomed

23
 SE UNIT-1 Afroze Begum (ASST. PROF.)CSE DCET

Disadvantages of Agile model:

 In case of some software deliverables, especially the large ones, it is difficult to assess the effort
required at the beginning of the software development life cycle.
 There is lack of emphasis on necessary designing and documentation.
 The project can easily get taken off track if the customer representative is not clear what final
outcome that they want.
 Only senior programmers are capable of taking the kind of decisions required during the
development process. Hence it has no place for newbie programmers, unless combined with
experienced resources.

When to use Agile model:

 When new changes are needed to be implemented. The freedom agile gives to change is very
important. New changes can be implemented at very little cost because of the frequency of new
increments that are produced.
 To implement a new feature the developers need to lose only the work of a few days, or even only
hours, to roll back and implement it.
 Unlike the waterfall model in agile model very limited planning is required to get started with the
project. Agile assumes that the end users’ needs are ever changing in a dynamic business and IT
world. Changes can be discussed and features can be newly effected or removed based on feedback.
This effectively gives the customer the finished system they want or need.
 Both system developers and stakeholders alike, find they also get more freedom of time and options
than if the software was developed in a more rigid sequential way. Having options gives them the
ability to leave important decisions until more or better data or even entire hosting programs are
available; meaning the project can continue to move forward without fear of reaching a sudden
standstill.

24
 SE UNIT-1 Afroze Begum (ASST. PROF.)CSE DCET

Extreme Programming (Xp)

Extreme Programming (XP), the most widely used approach to agile software development model.
More recently, a variant of XP, called Industrial XP (IXP) has been proposed. IXP refines XP and
targets the agile process specifically for use within large organizations.

XP Values:
A set of five values that establish a foundation for all work performed as a part of XP are as follows:

 Communication: In order to achieve effective communication XP emphasizes close, yet

informal (verbal) collaboration between customers and developers.
 Simplicity: To achieve simplicity, XP restricts developers to design only for immediate needs,
rather than consider future needs.
 Feedback: Feedback is derived from three sources-the implemented software itself, the
customer, and other software team members. By designing and implementing an effective
testing strategy, the software provides the agile team with feedback. As an increment is
delivered to a customer, the degree to which the software implements the output, function, and
behavior is a form of feedback. Finally, as new requirements are derived, the team provides the
customer with rapid feedback regarding cost and schedule impact.
 Courage: Strict adherence to certain XP practices demands courage.
 Respect: By following each of these values, the agile team inculcates respect among its
members, and indirectly, for the software itself.
Extreme Programming uses an object-oriented approach as its preferred development paradigm and
encompasses a set of rules and practices that occur within the context of four framework activities:
 Planning
 Design
 Coding
 Testing


25
SE UNIT-1 Afroze Begum (ASST. PROF.)CSE DCET

Key XP activities are as follows:

 Planning: The planning activity begins with listening—a requirements gathering activity that
enables the technical members of the XP team to understand the business context for the software
and to get a broad feel for required output and major features and functionality. Listening leads to
the creation of a set of “stories” also called user stories that describe required output, features, and
functionality for software to be built. Each story is written by the customer and is placed on an
index card. The customer assigns a value (i.e., a priority) to the story based on the overall business
value of the feature.Members of the XP team then assesses each story and assign a cost to it. If the
story is estimated to require more than three development weeks, the customer is asked to split the
story into smaller stories and the assignment of value and cost occurs again.
Customers and developers work together to decide how to group stories into the next release to be
developed by the XP team. Once a basic commitment is made for a release, the XP team orders the
stories that will be developed in one of three ways:
(1) All stories will be implemented immediately (within a few weeks),
(2) The stories with highest value will be moved up in the schedule and implemented first,
(3) The riskiest stories will be moved up in the schedule and implemented first.
After the first project release (also called a software increment) has been delivered, the XP team
computes project velocity- a measure of team productivity. Project velocity can then be used to
(1) Help estimate delivery dates and schedule for subsequent releases and
(2) Determine whether an over commitment has been made for all stories across the entire
development project. If an over commitment occurs, the content of releases is modified or end
delivery dates are changed.
As development work proceeds, the customer can add stories, change the value of an existing story,
split stories, or eliminate them. The XP team then reconsiders all remaining releases and modifies
its plans accordingly.

 Design: XP design rigorously follows the KIS (keep it simple) principle. A simple design is
always preferred over a more complex representation. In addition, the design provides
implementation guidance for a story as it is written—nothing less, nothing more. XP encourages
the use of CRC cards as an effective mechanism for thinking about the software in an object-
oriented context. CRC (class-responsibilitycollaborator) cards identify and organize the object-
oriented classes that are relevant to the current software increment. The XP team conducts the
design exercise. The CRC cards are the only design work product produced as part of the XP
process If a difficult design problem is encountered as part of the design of a story, XP
recommends the immediate creation of an operational prototype of that portion of the design.
Called a spike solution, the design prototype is implemented and evaluated. The intent is to lower
risk when true implementation starts and to validate the original estimates for the story containing
the design problem. XP encourages refactoring—a construction technique that is also a method for
design optimization. Refactoring is the process of changing a software system in such a way that it
does not alter the external behavior of the code yet improves the internal structure. It is a
disciplined way to clean up code that minimizes the chances of introducing bugs. In essence, when
you refactor you are improving the design of the code after it has been written. A central notion in
XP is that design occurs both before and after coding commences.

26
 SE UNIT-1 Afroze Begum (ASST. PROF.)CSE DCET

 Coding: After stories are developed and preliminary design work is done, the team does not move
to code, but rather develops a series of unit tests. Once the unit test has been created, the developer
is better able to focus on what must be implemented to pass the test. Nothing extraneous is added
(KIS). Once the code is complete, it can be unit-tested immediately, thereby providing
instantaneous feedback to the developers. A key concept during the coding is pair programming.
XP recommends that two people work together at one computer workstation to create code for a
story. This provides a mechanism for real time problem solving and real-time quality assurance. It
also keeps the developers focused on the problem at hand. As pair programmers complete their
work, the code they develop is integrated with the work of others. This is performed on a daily
basis by an integration team or by the pair programmers having the integration responsibility. This
“continuous integration” strategy helps to avoid compatibility and interfacing problems and
provides a “smoke testing” environment that helps to uncover errors early. 

 Testing: The creation of unit tests before coding commences is a key element of the XP approach.
The unit tests that are created should be implemented using a framework that enables them to be
automated hence; they can be executed easily and repeatedly. This encourages a regression testing
strategy whenever code is modified and then the integration and validation testing of the system
can occur on a daily basis. This provides the XP team with a continual indication of progress and
also can raise warning flags early if things go awry. Fixing small problems every few hours takes
less time than fixing huge problems just before the deadline. XP acceptance tests, also called
customer tests, are specified by the customer and focus on overall system features and functionality
that are visible and reviewable by the customer. Acceptance tests are derived from user stories that
have been implemented as part of a software release.

Advantages of Extreme Programming

 Fast:
Rather than develop software and a functioning system that takes potentially years, XP projects relatively
only last for several months. This is due to the fast paced work environment that XP implements, thus
reducing the amount of time wasted and working on what’s important during each iteration. All of this
allows continuous integration and deployment.
 Visible:
XP allows open communication between team members and development teams, this allows everyone to
keep up with the project advancement and progress.
Meetings are held regularly to make sure that everyone knows their tasks and to record the progress
made.
All of this will limit the number of bugs and failures in the system.
 Reduce costs:
Due to the fact that XP implements constant teamwork and feedback from the client, this allows changes
to be made when necessary and at the earliest time possible. These alterations in the requirements or any
new modifications required are implemented in the development period rather than at the end. Unlike the
Waterfall methodology, they have to wait to the very end for feedback, and depending on the change, it
could be detrimental for the project, hence why requirements must be very precise with Waterfall.
 Teamwork:
XP has an extremely strong influence on teamwork, which allows developers to accomplish the
requirements they were set out to do within tight deadlines.
 Strong relationship with the client:
27
 SE UNIT-1 Afroze Begum (ASST. PROF.)CSE DCET

XP strongly recommends that the project owner/client is available when needed so that any questions can
be asked or any revisions are to be made to obtain necessary feedback so it can be implemented in a more
efficient manner.
Disadvantages of Extreme Programming
 Code overcomes design:
XP focuses too much on the programming aspect of the system and its importance outweighs the design.
This can be disadvantageous if the particular system requires aesthetics to be one of it’s selling point or
important characteristics.
 Location:
XP project work at their best when the client and development team are close to each other (distance
wise) so they can meet face to face.
This limits the environments in which XP can be implemented due to many clients and development
teams tending to work using long distance mechanisms.
 Lack of documentation:
There is no hiding that XP allows for constant alterations with the project, however, these constant
changes are rarely document properly. This therefore allows a high risk of unexpected failures that cannot
be tracked, which then induces a domino effect that will inevitably end up reducing team efficiency and
productivity.
Even when the bugs are fixed, if there is no proper documentation, the same error or something similar
can surface again.
 Stress:
Due to the nature of XP and how it functions with tight deadlines, developers tend to have high stress
levels to complete tasks on time, thus increasing the chances of errors in the code. Subsequently, software
quality could be reduced due to the scheduling.

2.3.7 Using Process Models in a Project

We have seen many different development process models. What is the need for the different models? As
mentioned earlier, while developing (industrial strength) software, the purpose is not only to develop
software to satisfy the needs of some users or clients, but we want that the project be done in low cost and
cycle time, and deliver high-quality software. In addition, there could be other constraints in a project that
the project may need to satisfy. Hence,given the constraints of the project, we would like to employ the
process model that is likely to maximize the chances of delivering the software, and achieve the highest
Q&P. Hence, selecting a suitable development process model for a project is a key decision that a project
manager has to take. Let us illustrate this by a few examples.
Suppose a small team of developers has been entrusted with the task of building a small auction site for a
local university. The university administration is willing to spend some time at the start to help develop
the requirements, but it is expected that their availability will be limited later. The team has been given 4
months to finish the project, and an extension of the deadline seems very improbable. It also seems that
the auction site will have some features that are essential, but will also have some features that are
desirable but without which the system can function reasonably well.
With these constraints, it is clear that a waterfall model is not suitable for this project, as the “all or
nothing” risk that it entails is unacceptable due to the inflexible deadline. The iterative enhancement
model where each iteration does a complete waterfall is also not right as it requires requirements analysis
for each iteration, and the users and clients are not available later. However, the iterative delivery pproach
in which the complete requirements are done in the first iteration but delivery is done in iterations seems
well suited, with delivery being done in two (or three) iterations (as time is short). From
28
 SE UNIT-1 Afroze Begum (ASST. PROF.)CSE DCET

the requirements, the project team can decide what functionality is essential to have in a working system
and include it in the first iteration. The other desirable features can be planned for the second iteration.
With this approach, the chances of completing the first iteration before the final deadline increase. That
is, with this model, the chances of delivering a working system increase. RUP, as it allows iterations in
each phase, is also a suitable model.
Consider another example where the customers are in a highly competitive environment where
requirements depend on what the competition is doing, and delivering functionality regularly is highly
desirable. Furthermore, to reduce cost, the customer wants to outsource as much project work as possible
to another team in another country.
For this project, clearly waterfall is not suitable as requirements are not even known at the start. Iterative
enhancement also may not work as it may not be able to deliver rapidly. XP will be hard to apply as it
requires that the entire team, including the customer, be collocated. For this project, the timeboxing
model seems to fit the best. The whole project can employ three teams—one of analysts who will work
with the customer to determine the requirements, one to do the development (which could be in some
low-cost destination), and the third to do the deployment, which will be where the site is hosted. By
suitably staffing the teams, the duration of each of the three phases—analysis and design, build, and
deployment—can be made approximately equal. Then the timeboxing model can be applied.
Consider another project, where a university wants to automate the registration process. It already has a
database of courses and pre-requisites, and a database of student records. In this project, as the
requirements are well understood (since registrations have been happening manually), the waterfall
model seems to be the optimum.
2.4 Project Management Process
Project Management is a discipline about planning, monitoring, and controlling software projects,
identifying the scope, estimating the work involved, and creating a project schedule. Along with it is also
responsible to keep the team up to date on the project’s progress and handle problems and discuss
solutions.
It is a procedure of managing, allocating and timing resources to develop computer software that fulfills
requirements.
In software Project Management, the client and the developers need to know the length, period and cost
of the project.
There are three needs for software project management. These are:
1. Time
2. Cost
3. Quality
It is an essential part of the software organization to deliver a quality product, keeping the cost within the
client?s budget and deliver the project as per schedule. There are various factors, both external and
internal, which may impact this triple factor. Any of three-factor can severely affect the other two

29
 SE UNIT-1 Afroze Begum (ASST. PROF.)CSE DCET

Responsibilities of a Project Manager:

1. Managing risks and issues.
2. Create the project team and assigns tasks to several team members.
3. Activity planning and sequencing.
4. Monitoring and reporting progress.
5. Modifies the project plan to deal with the situation.
Activities

Software Project Management consists of many activities, that includes planning of the project, deciding the
scope of product, estimation of cost in different terms, scheduling of tasks, etc.

The list of activities are as follows:

1. Project planning and Tracking

2. Project Resource Management
3. Scope Management
4. Estimation Management
5. Project Risk Management
6. Scheduling Management
7. Project Communication Management
8. Configuration Management

30