Software Engineering

116U01C501

MODULE 1 1
MODULE 1: The Product and the Process (08)
CO 1: Understand the software development process and
Estimate different types of resources for the given project

1.1 Software Development Life Cycle models: Waterfall, RAD, Spiral ,

Agile process
1.2 Understanding software process, Process metric, CMM levels

1.3 Planning & Estimation: Product metrics estimations- LOC, FP,

COCOMO models

1.4 Project Management Activities: Planning , Scheduling & Tracking

MODULE 1 2
Definition of Software Engineering
• IEEE defines software engineering as: (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) Study of
approaches as in (1).
• Fritz Bauer defined Software engineering as the ―establishment
and use of sound engineering principles in order to obtain
economically software that is reliable and works efficiently on
real machines. ―

MODULE 1 3
4
5
6
7
8
9
Activities performed in life cycle of a Software
Development projects
Requirement
Analysis
5. Implementation
1. Requirement Analysis

Implementation Design

4. Testing
2. Design

Testing Development

3. Development
MODULE 1 10
Steps involved in Software Development

1. Identification of Problem
2. Problem Definition
3. Exploring approach(s) to solve the problem
4. Penning down/ finalizing the approach; listing the steps
5. Development
6. Testing
7. Deployment
8. Maintenance

These steps are iterative and some of them run parallel

MODULE 1 11
Generic Software Development Process Models

1. Code & Fix Model

2. Waterfall model
3. Rapid Application Development (RAD)
4. Spiral
5. Iterative
6. Evolutionary
7. Agile

MODULE 1 12
 Waterfall Model
Function
Requirements Requirement
Gathering & Analysis Software
Specifications
Requirement
System Design Specifications
Design
Software Document
design Source Code
Coding & Scripts

SW integration Test cases &

& verification test results

System
Verification
Source Code
& Scripts
Operation &
Maintenance
MODULE 1 13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Spiral Model

MODULE 1 32
• Why Spiral Model is called Meta Model?

• The Spiral model is called a Meta-Model because it subsumes

all the other SDLC models.
• For example, a single loop spiral actually represents the
Iterative Waterfall Model. The spiral model incorporates the
stepwise approach of the Classical Waterfall Model.
• The spiral model uses the approach of the Prototyping Model
by building a prototype at the start of each phase as a risk-
handling technique.
• Also, the spiral model can be considered as supporting the
Evolutionary model – the iterations along the spiral can be
considered as evolutionary levels through which the complete
system is built.
33
• Advantages of Spiral Model:
• Below are some advantages of the Spiral Model.
• Risk Handling: The projects with many unknown risks that occur as the development proceeds,
in that case, Spiral Model is the best development model to follow due to the risk analysis and
risk handling at every phase.
• Good for large projects: It is recommended to use the Spiral Model in large and complex
projects.
• Flexibility in Requirements: Change requests in the Requirements at later phase can be
incorporated accurately by using this model.
• Customer Satisfaction: Customer can see the development of the product at the early phase of
the software development and thus, they habituated with the system by using it before completion
of the total product.
• Iterative and Incremental Approach: The Spiral Model provides an iterative and incremental
approach to software development, allowing for flexibility and adaptability in response to changing
requirements or unexpected events.
• Emphasis on Risk Management: The Spiral Model places a strong emphasis on risk
management, which helps to minimize the impact of uncertainty and risk on the software
development process.
• Improved Communication: The Spiral Model provides for regular evaluations and reviews,
which can improve communication between the customer and the development team.
• Improved Quality: The Spiral Model allows for multiple iterations of the software development
process, which can result in improved software quality and reliability

34
35
36
37
 Agile
•Effective (rapid and adaptive) response to change (team members, new technology, requirements)
•Effective communication in structure and attitudes among all team members, technological and
business people, software engineers and managers
•Involving the customer into the team
•Working as a team
•Planning in an uncertain world has its limits and plan must be flexible
•Organizing a team so that it is in control of the work performed
•Eliminate all but the most essential work products and keep them lean
•Emphasize an incremental delivery strategy as opposed to intermediate products that gets
working software to the customer as rapidly as feasible.
•Rapid, incremental delivery of software

MODULE 1 38
39
 Extreme Programming (XP)
Test Driven Development
Recommends the construction of test cases before coding commences. So implementer can focus on what must be
implemented to pass the test
Pair Programming
Encourages “pair programming”. Two people work together at one workstation. Real time problem solving, real time review
for quality assurance. Take slightly different roles
Incremental Development
Come up with increments every few days to avoid drawbacks of waterfall model
Simplicity is good
Create simplest design that will support only the current required functionality(less bugs, easy to maintain and test)
Refactoring
Refactoring is an activity to improve a code or component’s internal structure or operation without changing its external
behavior. The goal of software development is the continuous delivery of business value to users and stakeholders.
Constantly changing technology and evolving business objectives
Metaphor
It provides a simple, concrete idea or image used to help understand complex or abstract concepts and guide the
development process.
Continuous Integration
Don’t integrate after fully development
 4 values of XP
• Communication: Enhance communication among team members and with
the customers
• Simplicity: build something that will work today, may not work tomorrow
• Feedback: Take continuous feedback of customers. Make customer part
of the team
• Courage: If code structure has become bad don’t hesitate to discard it
and rewrite new code

MODULE 1 41
42
43
Scrum

MODULE 1 44
45
46
47
48
49
50
 Adaptive Software Development (ASD)
Focusing on human collaboration and team self-organization as a
technique to build complex software and system
Distinguishing features
•Mission-driven planning
•Component-based focus
•Uses “time-boxing” focus of Project Management Concepts
•Explicit consideration of risks
•Emphasizes collaboration for requirements gathering
•Emphasizes “learning” throughout the process

MODULE 1 51
 Three Phases of ASD
1. Speculation: project is initiated and adaptive cycle planning is
conducted
•Adaptive cycle planning uses project initiation information- the
customer’s mission statement, project constraints (e.g. delivery
date), and basic requirements to define the set of release cycles
(increments) that will be required for the project.
•Based on the information obtained at the completion of the first
cycle, the plan is reviewed and adjusted so that planned work
better fits the reality.

MODULE 1 52
 Three Phases of ASD
2. Collaborations are used to multiply their talent and creative output
beyond absolute number (1+1>2).
It encompasses communication and teamwork, but it also emphasizes
individualism, because individual creativity plays an important role in
collaborative thinking
It is a matter of trust.
•criticize without animosity
•assist without resentments
•work as hard as or harder than they do
•have the skill set to contribute to the work at hand
•communicate problems or concerns in a way that leads to effective
action.

MODULE 1 53
 Three Phases of ASD
3. Learning: As members of ASD team begin to develop the components, the
emphasis is on “learning”.
•software developers often overestimate their own understanding of the
technology, the process, and the project and that learning will help them to
improve their level of real understanding.
•Three ways: focus groups, technical reviews and project post-mortems

MODULE 1 54
Three Phases of ASD

MODULE 1 55
 Dynamic Systems Development Method (DSDM)
Provides a framework for building and maintaining systems which meet tight time constraints
through the use of incremental prototyping in a controlled project environment
Supports RAD model and Iterative Principal
Works on Pareto Principal 80 % of An application is often delivered in twenty percent of the time
•Similar in most respects to XP and/or ASD
•Guiding principles
1.Active user involvement is imperative.
2.DSDM teams must be empowered to make decisions
3.The focus is on frequent delivery of products
4.Fitness for business purpose is the essential criterion for acceptance of deliverables
5.Iterative and incremental development is necessary to converge on an accurate business solution
6.All changes during development are reversible
7.Testing is integrated throughout the life-cycle
MODULE 1 56
57
Assignment
Compare various Software Development Life Cycle
models
Compare prototype and incremental model
Compare waterfall and spiral model

MODULE 1 58
Software Engineering A Layered
Technology

59
• Any engineering approach (including software engineering) must
rest on an organizational commitment to quality.
• Process defines a framework for a set of key process areas (KPAs)
that must be established for effective delivery of software
engineering technology.
• The key process areas include:
• management control of software projects,
• Application of technical methods,
• work products (models, documents, data, reports, forms, etc.) are
produced,
• milestones are established,
• quality is ensured,
• and change is properly managed.

60
• Software engineering methods provide the technical how-to's
for building software. Methods encompass a broad array of
tasks that include requirements analysis, design, program
construction, testing, and support.
• Software engineering tools provide automated or semi-
automated support for the process and the methods.

61
THE SOFTWARE PROCESS
Characterized by:
•Common process framework established by defining a small number of framework activities that
are applicable to all software projects, regardless of their size or complexity

MODULE 1 62
 Process Framework activities
• Work tasks
• Work products
• Milestones & Deliverables
• Quality Assurance Check points
The following generic process framework is applicable to the vast majority of S/W projects.
• Communication: By communication, customer requirement gathering is done. Communication with
consumers and stakeholders to determine the system’s objectives and the software’s requirements.
• Planning: Establish engineering work plan, describes technical risk, lists resources requirements, work
produced and defines work schedule.
• Modeling: Architectural models and design to better understand the problem and for work towards the
best solution. The software model is prepared by:
o Analysis of requirements
o Design
• Construction: Creating code, testing the system, fixing bugs, and confirming that all criteria are met.
The software design is mapped into a code by:
o Code generation
o Testing
• Deployment: In this activity, a complete or non-complete product or software is represented to the
customers to evaluate and give feedback. On the basis of their feedback, we modify the product for the
supply of better products.
• Each engineering action defined by a framework activity comprises a list of needed work outputs,
project milestones, and software quality assurance (SQA) points.
MODULE 1 63
 Process Umbrella activities
Typical Umbrella activities include:
• Software project tracking and control
• Formal technical reviews
• Software quality assurance
• Software configuration management
• Document preparation and production
• Reusability management
• Measurement
• Risk management
Umbrella activities are applied throughout the software process

MODULE 1 64
 Process Maturity
Software Engineering Institute (SEI) has developed a comprehensive
model predicated on a set of software engineering capabilities that should
be present for an organization when the organization reaches different
levels of process maturity.

Five levels usually it is termed as Capability Maturity Model (CMM) Levels

CMM is a strategy for improving the software process, to generate quality
software.

MODULE 1 65
CMM Levels

MODULE 1 66
 CMM Levels
•Level 1: Initial. The software process is characterized as ad hoc and occasionally even
chaotic. Few processes are defined, and success depends on individual effort.
•Level 2: Repeatable (Managed). Basic project management processes are established to
track cost, schedule, and functionality. The necessary process discipline is in place to repeat
earlier successes on projects with similar applications.(No documentation, no training, no
improvement, no process documentation)
•Level 3: Defined. The software process for both management and engineering activities is
documented, standardized, and integrated into an organization-wide software process. All
projects use a documented and approved version of the organization's process for
developing and supporting software. This level includes all characteristics defined for level 2.
•Level 4: Managed (Quantitively managed). Detailed measures of the software process and
product quality are collected. Both the software process and products are quantitatively
understood and controlled using detailed measures. This level includes all characteristics
defined for level 3.
•Level 5: Optimizing. Continuous process improvement is enabled by quantitative feedback
from the process and from testing innovative ideas and technologies. This level includes all
characteristics defined for level 4.
MODULE 1 67
 Key Process Areas (KPA)
•The SEI has associated key process areas (KPAs) with each of the maturity
levels which describe those software engineering functions (e.g., software
project planning, requirements management) that must be present to satisfy
good practice at a particular level.
•Characteristics Of KPAs
•Goals—the overall objectives that the KPA must achieve.
•Commitments—requirements (imposed on the organization) that must be met to
achieve the goals or provide proof of intent to comply with the goals.
• Abilities—those things that must be in place (organizationally and technically) to enable
the organization to meet the commitments.
•Activities—the specific tasks required to achieve the KPA function.
•Methods for monitoring implementation—the manner in which the activities are
monitored as they are put into place.
•Methods for verifying implementation—the manner in which proper practice for the
KPA can be verified.
MODULE 1 68
 KPAs of CMM Level 2
•Process maturity level 2 (Repeatable /managed)
Goals, Commitments, Abilities, Activities, Methods for monitoring implementation,
Methods for verifying implementation

•Software configuration management

•Software quality assurance
•Software subcontract management
•Software project tracking and oversight
•Software project planning
•Requirements management

MODULE 1 69
 KPAs of CMM Level 3
•Process maturity level 3 (Defined)
Goals, Commitments, Abilities, Activities, Methods for monitoring implementation,
Methods for verifying implementation achieved through:
•Peer reviews
•Intergroup coordination
•Software product engineering
•Integrated software management
•Training program
•Organization process definition
•Organization process focus

MODULE 1 70
 KPAS of CMM Level 4 & 5
•Process maturity level 4 Managed (Quantitatively managed)
Goals, Commitments, Abilities, Activities, Methods for monitoring implementation,
Methods for verifying implementation
● Software quality management
● Quantitative process management

•Process maturity level 5 (Optimized)

• Process change management
• Technology change management
• Defect prevention

MODULE 1 71
Process and Product Metrics
• Enables software people to gain insights into efficiency of the
software process and project.
• Basic data are collected and analyzed compared against past
assessed data to determine whether quality and productivity
improvement has occurred.
• Metrics are also used to pinpoint problem areas, so remedies
can be developed and software process can be improved.
• Who does it?
• Software metrics are analyzed and assessed by Software
Managers
• Measures are collected by Software Engineers

72
Measure, Measurement, Metrics & Indicators
When a single data point has been collected (e.g., the number of errors
uncovered in the review of a single module), a measure has been established.
Measurement occurs as the result of the collection of one or more data points
(e.g., a number of module reviews are investigated to collect measures of the
number of errors for each).
A software metric relates the individual measures in some way (e.g., the
average number of errors found per review).
A software engineer collects measures and develops metrics so that indicators
will be obtained.
An indicator is a metric or combination of metrics that provide insight into the
software process, a software project, or the product itself . An indicator
provides insight that enables the project manager or software engineers to
adjust the process, the project, or the process to make things better.

MODULE 1 73
METRICS IN THE PROCESS AND
PROJECT DOMAINS
• Process indicators enable a software engineering organization to gain
insight into the efficacy of an existing process (i.e., the paradigm,
software engineering tasks, work products, and milestones).
• They enable managers and practitioners to assess what works and what
doesn’t. Process metrics are collected across all projects and over long
periods of time.
• Their intent is to provide indicators that lead to long-term software
process improvement.
• Project indicators enable a software project manager to (1) assess the
status of an ongoing project, (2) track potential risks, (3) uncover
problem areas before they go―critical,‖ (4) adjust work flow or tasks, and
(5) evaluate the project team’s ability to control quality of software work
products.

74
 Software Process Metrics
Software process metrics can provide significant benefit as an organization
works to improve its overall level of process maturity.
The only rational way to improve any process is to measure specific attributes
of the process, develop a set of meaningful metrics based on these attributes,
and then use the metrics to provide indicators that will lead to a strategy for
improvement.

MODULE 1 75
• We measure the efficacy of a software process indirectly. That
is, we derive a set of metrics based on the outcomes that can
be derived from the process.
• Outcomes include measures of errors uncovered before
release of the software, defects delivered to and reported by
end-users, work products delivered (productivity), human
effort expended, calendar time expended, schedule
conformance, and other measures.
• We also derive process metrics by measuring the
characteristics of specific software engineering tasks.
• For example, we might measure the effort and time spent
performing the umbrella activities and the generic software
engineering activities described
76
• A ―software metrics etiquette‖ that is appropriate for both
managers and practitioners as they institute a process metrics
program:

77
 SSPI
Statistical software process improvement (SSPI):
•the collection and use of process metrics, the derivation of simple indicators gives way to a
more rigorous approach.
•SSPI uses software failure analysis to collect information about all errors and defects
encountered as an application, system, or product is developed and used.

Failure analysis works in the following manner:

1. All errors and defects are categorized by origin (e.g., flaw in specification, flaw in logic,
non-conformance to standards).
2. The cost to correct each error and defect is recorded.
3. The number of errors and defects in each category is counted and ranked in descending
order.
4. The overall cost of errors and defects in each category is computed.
5. Resultant data are analyzed to uncover the categories that result in highest cost to the
organization.
6. Plans are developed to modify the process with the intent of eliminating (or reducing the
frequency of) the class of errors and defects that is most costly.
MODULE 1 78
Failure Analysis

MODULE 1 79
• Following steps 1 and 2, a simple defect distribution can be
developed. eight causes of defects and their origin are shown.

80
 Software Project metrics
•Software project measures are tactical; project metrics and the indicators derived from
them are used by a project manager and a software team to adapt project workflow and
technical activities.
•The first application of project metrics on most software projects occurs during
estimation.
•Metrics collected from past projects are used as a basis from which effort and time
estimates are made for current software work.
•As a project proceeds, measures of effort and calendar time expended are compared to
original estimates (and the project schedule). The project manager uses these data to
monitor and control progress.
As the software evolves from specification into design, technical metrics are collected to
assess Specification defects design quality and to provide indicators that will influence the
approach taken to code generation and testing.
Used to :
1. minimize the development schedule by making the adjustments necessary to avoid
delays and mitigate potential problems and risks.
2. assess product quality on an ongoing basis and, when necessary, modify the technical
approach to improve quality. MODULE 1 81
 Software Measurement
•Direct measures of the software engineering process include cost
and effort applied.
•Direct measures of the product include lines of code (LOC)
produced, execution speed, memory size, and defects reported over
some set period of time.

•Indirect measures of the product include functionality, quality,

complexity, efficiency, reliability, maintainability

MODULE 1 82
 Types of Software product Metrics
1. Size-Oriented Metrics
•metrics derived by normalizing quality and/or productivity measures by
considering the size of the software that has been produced
•a set of simple size-oriented metrics can be developed for each project:
• Errors per KLOC (thousand lines of code).
• Defects per KLOC.
• $ per LOC.
• Page of documentation per KLOC.
In addition, other interesting metrics can be computed:
• Errors per person-month.
• LOC per person-month.
• $ per page of documentation.

MODULE 1 83
 Product Metrics
2. Function-oriented Metrics
•software metrics use a measure of the functionality delivered by the
application
•Function points derived from direct measures of the information domain.
1.Number of user inputs. Each user input that provides distinct application oriented data to the
software
2.Number of user outputs. Each user output that provides application oriented information to the user
is counted. In this context output refers to reports, screens, error messages, etc.
3.Number of user inquiries. An inquiry is defined as an on-line input that results in the generation
of some immediate software response in the form of an on-line output.
4.Number of files. Each logical master file (i.e., a logical grouping of data that may be one part of a
large database or a separate file) is counted.
5.Number of external interfaces. All machine readable interfaces (e.g., data files on storage media)
that are used to transmit information to another system are counted.

MODULE 1 84
 Product Metrics
FP calculation

FP = Count total * ( 0.65 + 0.01 * ∑ Fi)

MODULE 1 85
 Software Measurement
The Fi (i = 1 to 14) are "complexity adjustment values" based on responses to the following questions
1. Does the system require reliable backup and recovery?
2. Are data communications required?
3. Are there distributed processing functions?
4. Is performance critical?
5. Will the system run in an existing, heavily utilized operational environment?
6. Does the system require on-line data entry?
7. Does the on-line data entry require the input transaction to be built over multiple screens or operations?
8. Are the master files updated on-line?
9. Are the inputs, outputs, files, or inquiries complex?
10. Is the internal processing complex?
11. Is the code designed to be reusable?
12. Are conversion and installation included in the design?
13. Is the system designed for multiple installations in different organizations?
14. Is the application designed to facilitate change and ease of use by the user?
•Each of these questions is answered using a scale that ranges from 0 (not important or applicable) to 5
(absolutely essential)

MODULE 1 86
 Software Measurement
Given the following values, compute function point when all complexity
adjustment factor (CAF) are average and weighting factors are
•User Input = 40 Simple
•User Output = 35 Complex
•User Inquiries = 30 Simple
•User Files = 8 Average
•External Interface = 6 Average
Count Total = 40* 3 + 35 * 7 + 30 * 3 + 8 *10 + 6 *7 = 577
Σ(Fi) = 14* 3 = 42 (total 14 Fi Each is average on scale of 1-5 hence
3)
FP = count total [0.65 + 0.01 Σ(Fi)]
FP = 577 * (0.65+ 0.42)
= 617.39
MODULE 1 87
88
89
90
 Software Product Estimation
COCOMO model
•Constructive Cost Estimation Model
•Basic Effort Estimation Model uses size of Code to estimate man month
effort and project duration in month
•Effort: Amount of labour that will be required to complete a task. It is
measured in person-months units.
•Schedule: Simply means the amount of time required for the completion of
the job, which is, of course, proportional to the effort put. It is measured in
the units of time such as weeks, months.

MODULE 1 91
 COCOMO
•Software are categorized into :
1.Organic:if the team size required is adequately small, the problem is well understood
and has been solved in the past and also the team members have a nominal experience
regarding the problem.
2.Embedded Projects: A software project with requiring the highest level of complexity,
creativity, and experience requirement fall under this category. Such software requires a
larger team size than the other two models and also the developers need to be sufficiently
experienced and creative to develop such complex models.
3. Semi-detached projects: if the vital characteristics such as team-size, experience,
knowledge of the various programming environment lie in between that of organic and
Embedded.
The projects classified as Semi-Detached are comparatively less familiar and difficult to
develop compared to the organic ones and require more experience and better
guidance and creativity. Eg: Compilers or different Embedded Systems can be
considered of Semi-Detached type.

MODULE 1 92
 COCOMO
Coefficients Related to Basic Model
Estimation at the early design stage where ONLY User Requirements are
defined
Effort= a* (KLOC)b
Project Duration = c* (Effort)d (represented in Months)
Person Required = Effort /Project Duration

Development Model a b c d
Organic 2.4 1.05 2.5 0.38
Embedded 3.6 1.20 2.5 0.32
Semi detached 3.0 1.12 2.5 0.35
MODULE 1 93
• Suppose a project manager has used FP analysis to estimate
lines of source code required to develop a project and finds
that the code size is 10,000. Estimate duration of the project
and number of persons required.
• Assume the project is classified as Embedded Project.
• b) Assume the project is classified as Organic Project.

94
 Intermediate COCOMO
Effort= a*EAF* (KLOC)b

MODULE 1 95
 Intermediate COCOMO
EAF = Early Adjustment Cost Factors:

MODULE 1 96
 Software Project Planning
• .The objective of software project planning is to provide a framework that enables to
make a resonable estimation to determine how much money, how much effort, how
many resources, and how much time it will take to build a specific software-based
system or product
• •Performed by Software managers—using information solicited from customers and
software engineers and software metrics data collected from past projects
• •Projects being costly it is reasonable to develop an estimate before you start
creating the software.
• •Estimation begins with a description of the scope of the product, decomposed into a
set of smaller problems and each of these is estimated using historical data and
experience as guides.
• •It is advisable to generate your estimates using at least two different methods (as a
cross check)
• •Problem complexity and risk are considered before a final estimate is made.
• •Estimates should attempt to define best case and worst case scenarios so that
project outcomes can be under control.

97
 Steps for Project Planning
Scope (What to develop)
• Check Feasibility(―Can we build software to meet this scope?)
• Resources required (role, number, when will be available etc.)

• Project Estimation(time and cost)

• Identify risks

98
99
Reasons for late delivery of products
•An unrealistic deadline established by someone outside the software
development 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.

100
• Remedies:
• •Perform a detailed estimate using historical data from past
projects. Determine the estimated effort and duration for the
project.
• •Using an incremental process model, develop a 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.

101
Project Scheduling
• An activity that distributes estimated effort across the planned
project duration by allocating the effort to specific tasks
• •specific software tasks are identified and scheduled
• •the schedule evolves over time
• •During early stages of project planning, a macroscopic schedule
is developed identifying all major activities and the product
functions to which they are applied.
• •As the project gets under way, refine into a detailed schedule.
• •Two approaches:
• •Based on the end-date for release distribute effort within the
prescribed time frame
• •Based on the time required for each activity, decide the end date

102
Basic principle guides of Scheduling
• •Compartmentalization: Break into a number of manageable activities and tasks by
decomposing both the product and the process
• •Interdependency: The interdependency of each compartmentalized activity or task
must be determined. Some tasks must occur in sequence while others can occur in
parallel. Some activities cannot commence until the work product produced by another
is available. Other activities can occur independently.
• •Time allocation Each task to be scheduled must be allocated some number of work
units (e.g., person-days of effort). In addition, each task must be assigned a start date
and a completion date that are a function of the interdependencies and whether work
will be conducted on a full-time or part-time basis.
• •Effort validation. Every project has a defined number of staff members. 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. For example, consider a
project that has three assigned staff members (e.g., 3 person-days are available per
day of assigned efforts). On a given day, seven concurrent tasks must be
accomplished. Each task requires 0.50 person days of effort. More effort has been
allocated than there are people to do the work.
•

103
• •Define responsibilities Every task that is scheduled should be
assigned to a specific team member.
• •Define outcomes Every task that is scheduled should have a
defined outcome. For software projects, the outcome is normally a
work product (e.g., the design of a module) or a part of a work
product. Work products are often combined in deliverables.
• •Define 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.
•

104
Defining Task set
• Irrespective of the process model used for development, task
set that enable a software team to define, develop, and ultimately
support computer software.
• •A task set is a collection of software engineering work tasks,
milestones, and deliverables that must be accomplished to
complete a particular project.
• •The task set to be chosen must provide enough discipline to
achieve high software quality.
• •It must NOT burden the project team with unnecessary work.
• •In order to develop a project schedule, a task set must be
distributed on the project timeline.
•

105
• Based on phase of the project identify the various major tasks
• Concept , Analysis , Design, Coding, Maintenance
• •Concept scoping determines the overall scope of the project.
• •Preliminary concept planning establishes the organization’s ability to
undertake the work implied by the project scope.
• •Technology risk assessment evaluates the risk associated with the
technology to be implemented as part of project scope.
• •Proof of concept demonstrates the viability of a new technology in the
software context.
• •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.
• •Customer reaction to the concept solicits feedback on a new
technology concept and targets specific customer applications.
•

106
Sample Linear Development Approach Tasks

107
108
• Project Scheduling methods:
• •Critical Path Method (CPM)
• •Program Evaluation & Review Technique (PERT)
•
Tools:
• •Timeline Chart/ Gantt Chart
• •MicroSoft Project Tool used for scheduling
•

109
110
Tracking the Schedule
• •The project schedule provides a road map
• •Properly developed project schedule defines the tasks and milestones that
must be tracked and controlled as the project proceeds
• •Tracking can be accomplished by:
• •Conducting periodic project status meetings in which each team member
reports progress and problems.
• •Evaluating the results of all reviews conducted throughout the software
engineering process.
• •Determining whether formal project milestones (the diamonds shown in Figure)
have been accomplished by the scheduled date
• •Comparing actual start-date to planned start-date for each project task listed in
the resource table
• •Meeting informally with practitioners to obtain their subjective assessment of
progress to date and problems on the horizon.
• •Using earned value analysis to assess progress quantitatively.

111
112
113
114