Chapter -2 (planning a software project)

2.1 Defining The Problem

Defining the Problem :
• s/w development organizations are very selective in deciding
which products to develop.
• The decision to proceed is usually based on the outcome of a
feasibility study.
• 1st step: defining problem:
• A concise statement of the problem to be solved and the constraints that exist
for its solution.
– Includes description of present situation.
– Goals to be achieved by the new system.
• Problem definition requires thorough understanding of the problem domain
 Includes customer interviews, observation of problem task, and actual performance task by
the planner.
 Planner must highly skilled
 2.1 Defining The Problem
• 2nd step :
• Determine the appropriateness of a computerized solution.
• Cost effective, socially and politically acceptable.
• Economically and technically feasible.
Must provide same service and information as old system using less time.
• Build the computing system to find the remedy for the root cause of the
problem.
• Computerized solution should be appropriate.
• Attention should focused on the roles to be played by the major sub system of
computing system.
• Computing system consists of
• People subsystem: operators, maintenance personal and end users.
• H/w subsystem: computing h/w, peripheral devices, process control, actuators or tracking
antenna and radars.
• S/ W sub system: s/w to be developed, existing s/w.
 2.1 Defining The Problem
• Function in each sub system should
• Identified.
• Interaction between sub systems must be established.
• Developmental and operational constraint must be
determined.
• Constraints specify the no., and types of equipment,
numbers and skill levels of personnel and s/w
characteristics such as
• Performance
• Accuracy
• Level of reliable
 2.1.1 Goals and Requirements
Goals :
•Targets for achievement and serve as a frame work for s/w
development project.
•Apply to both development process and the work products.
•Goals can be either qualitative or quantitative.
i) Qualitative
Qualitative process Goal : the development process should enhance
the professional skills of quality assurance personnel.
Qualitative product Goal : The system should make users job more
interesting.
ii) Quantitative
Quantitative process Goal : should be delivered within 12 months.
Quantitative product Goal : the system should reduce the cost of a
transaction by 25 percent.
•Goals apply to every project and product.
•Every product should be
•Useful
•Reliable
•Understandable and
•Cost-effective
•Every development process should deliver work
products
•On time
•Within cost estimates and
•Provide opportunity to learn new skills.
 Requirements
It specify capabilities that a system must provide in
order to solve problem. Include
•Functional requirements.
•Performance requirements.
•Requirements for the h/w, firmware, s/w and user
interfaces.
•Specify development standards and quality
assurance standards for both project and product.
•Quantified whenever possible
•Quantified Requirements such as
Phase accuracy shall be with in .5 degree
Response to external interrupts shall be .25 sec maximum
System shall reside in 50k bytes of primary memory, excluding the buffer.
System shall be 99 percent reliable.
• Qualitative Requirements:
 Accuracy shall be sufficient to support mission.
 System shall provide real-time response.
 Shall make efficient use of primary memory.
 Shall be 99 percent reliable.

• High level goals and requirements

• Can be expressed in term of quality attributes
• For eg Reliability in terms of source code accuracy, robustness,
completeness and consistency.
• Refer S/W quality characteristic tree.
• established during planning phase.
• Can be expressed in terms of attributes built in to work product
• Important to established the high-level acceptance criteria during
planning phase.
S/W Quality Characteristic Tree
(OR)
Source Code Attributes
• Lack of clearly stated, quantified acceptance criteria lead to serious
misunderstanding between customer and developer.
• Plans describe the mechanism to be used in achieving goals and requirements.

• MileStone:
• Is a significant event in the s/w product life cycle.
• Eg completion of requirement analysis, completion of design, and integration and successful
testing of all system components.
• Plan to Reach Mile stones:
• How many milestones are appropriate?
• When do they occur?
• What resources are required to reach each milestone?
• Who will be responsible for achievement of each milestone?
• What must be true to permit achievement of each milestone?
• Exactly what will constitute achievement of each milestone?
Some Factors to Consider in Project Planning

• Estimation technique to be used; accuracy required.

• Life-Cycle model, control functions and reviews
• Organizational Structure
• Level of formality in specifications, test plans, etc.
• Level of verification and validation
• Level of configuration management required
• Level of quality assurance required.
• Follow-on maintenance responsibilities
• Tools to be developed and used
• Personnel recruitment and training
 Some Factors To Consider In Setting Project
Goals
1. New capabilities to be provided.
2. Old capabilities to be preserved.
3. level of user sophistication.
4. Efficiency requirements.
5. Reliability requirements.
6. Likely modifications.
7. Early subsets and implementation priorities.
8. Portability requirements.
9. Security concerns.
 2.2 Developing a Solution Strategy
• Tendency to adopt the first solution that occurs to developer is the major
problem.
• To avoid this is to develop a solution strategy.
• Detailed solution plan
• Strategy factors are
• Batch or time sharing
• Database or File system
• Graphics or Text
• Real time or off line processing

• Should account for all external factors visible to the product users
• Should be phrased to permit alternative approaches to product design.
• Solution strategies should provide feasibility studies and cost estimates.
• Provide a framework for design and implementation of s/w product.
• Solution strategy should be generated without regard for
feasibility.
• An unreasonable idea will lead to other ideas, which may be
reasonable.
• Best strategy
• composite of ideas from several different approaches.
• Become apparent only after enumerated all possible ideas.
• Feasibility can be established by examining
solution constraints.
• Prescribe the boundaries of the solution space.
• Feasibility analysis determines proposed strategy is with in boundary.
• Solution strategy is feasible if the project goal and
requirements can be satisfied with in the constraints of
• Available time
• Resources
• Technology
• Techniques for determines feasibility of a solution
strategy includes
• Case studies.
• Worst case analysis.
• Simulation.
• Construction of prototypes.
• Prototype incorporates some components of actual
system. Its implementations have
• Limited functionality.
• Low reliability.
• Poor performance characteristics.
• Constructed during the planning phase to examine
» Technical issues
» Simulate users displays
» Report formats
» Dialogues
• Documentation is extremely important when the
strategy is recommended.
• Should state the reason for rejecting other strategy
• Provides justification for the recommended strategy.
• May prevent ill-considered revisions at some later date.
• Priority list should include in the solution strategy.
• During the development life cycle it may be necessary to
postpone or eliminate some system capabilities due to
inconsistencies in the
» Requirements
» Technical bottle necks
» Time and cost over runs
• Without the priority list designer or programmer may make serious
mistakes in judgments.
• Also useful to indicate the manner in which capabilities can be developed
and phased into an evolving system.
• Useful in planning the successive versions to be built
 2.3 Planning The development Process
• Several important considerations
• Define a product life cycle model
– Encompasses all activities required to
» Define
» Develop
» Test deliver operate and
» Maintain s/w concerned parties improves
» This model accepted by all and improves
• Project communication
• Enhances manageability
• Resource allocation
• Cost control
• Product quality
 The Phased Life-Cycle Model
• Series of successive activities
• Each phase requires
• Well-defined i/p information.
• Utilizes well-defined process.
• Results in well-defined products.
• Resources are required to complete the process in each
phase.
• Each phase is accomplished the application of explicit
• Methods
• Tools
• Techniques.
 Waterfall Chart
• Analysis 2 phase
• Planning
• Requirement Definition
• Design phase
• Architecture Details
• Implement phase
• Code
• Debug
• Unit test
• System test
• Integration Acceptance
• Maintenance phase
• Enhance
• Adapt
• Fix
ANALYSIS DESIGN PHASE IMPLEMENT SYSTEM MAINTENANCE
PHASE PHASE TESTING PHASE

Planning
Requirement
Definition
Architecture
details Code
Verify Debug
Unit test
verify
verify Integration
Acceptance
verify Enhance
Adapt
fix

PFR SRR PDR C DR SCRs A TR P RR

P PM
1. Analysis:
• 2 phases
1. Planning :
• Includes understanding customer problem
• Performing feasibility study
• Developing a recommended solution strategy
• Determining the acceptance criteria.
• Planning the development process.
• Cost estimation and work schedule.
(i) System Definition:
• Expressed in English or in natural language,
• May incorporate Charts, Figure3s, Graphs, Tables and
Equations
 Format of System Definition
• Problem Definition
• System justification
• Goals for the system and the project
• Constrains on the system]functions to be provided
• User characteristics
• Development/operating/maintenance environments
• Solution strategy
• Priorities
• System acceptance
• Sources of information
• Glossary of terms
II. Project Plan :
• Contains Life cycle model to be used
• The organizational structure for the project
• Preliminary development schedule
• Preliminary Cost and resource estimates
• Preliminary staffing requirements
• Tools and techniques to be used
• Standard practice to be followed.
 Format of a Project Plan
• Life cycle Model
• Organizational structure
• Preliminary staffing
• Preliminary cost
• Project monitoring and control mechanism
• Tools and techniques to be used
• Programming Languages
• Testing Requirements
• Supporting documents required
• Manner of demonstration and Delivery
• Training Schedule
• Installation Plan
• Maintenance Considerations
• Method and Time of delivery
• Sources of Information
2) Requirements definitions :
• Identifying the basic functions of the s/w components in
a h/w, s/w, people system.
• Deciding exactly how the s/w will be implemented.
• Product requirement definition is a specification that
describe processing environment, required s/w
functions, performance constraints on the s/w(size,
speed, machine configuration)
• Exception handling
• Implementation priority
• Acceptance criteria.
2. Design
• Identifying s/w components
• Functions, DataStream and data stores
• Specify the relationship among the components.
• Specify the s/w structure
• Maintaining the record of design decisions
• Provide blue print for the implementation.
i) Architectural Design
• Identifying the s/w components
• Decoupling and decomposing them into processing modules
• Conceptual data structure
• Interconnection among components
ii) Detailed Design:
• Concern with how to package the processing module
• How to implement the processing algorithms, data
structures and interconnection among modules and
data structures.
• Adaptation of existing code
• Modification of standard algorithm
• Invention of new algorithm
• Design of data representation
• Packaging of s/w product
• Strongly influenced by programming language
3. Implementation Phase:

• Translation of design specifications into source code.

• Debugging
• Documentation
• Unit Testing
• Modern programming languages support Enhance the quality of source code
by
• Structured control
• Built-in and user defined data types.
• Secure type checking
• Flexible scope rules.
• Exception handling mechanism
• Concurrency constructs
• Separate compilation of modules
• Error discovered includes
• Error in the interface between routines
• Logical error in the algorithm
• Error in data structure layout
• Requirement error
4. System Testing
• 2 kinds of activities
1. Integration Testing:
• Developing a strategy for integrating the components
of a s/w into a functioning whole requires careful
planning.
2. Acceptance Testing :
• Planning and execution of various types of tests in order to
demonstrate that the implemented s/w system satisfies the
requirements stated in the requirement document.

5. Maintenance :
• Enhancement of capabilities.
• Adaption of the s/w to new processing environments
• Correction of s/w bugs.
 2.1 Defining The Problem
• Analysis consist of 2 sub phases :
1. Planning and
2. Requirements Definitions
Defining the Problem :

1. Develop a defined statement of the problem to be solved,

• include a description of the present situation,
• problem constraints, and
• a statement of the goals to be achieved
• The statement should be phrased in the customer terminology.
2. Justify a computerized solution strategy for the problem.
3. Identify the function to be provided by, and the constraints on, the h/w subsystem,
the s/w subsystem, and the people subsystem.
4. Determine system-level goals and requirements for the development process and the
work products.
5. Establish high-level acceptance criteria for the system.
Developing a Solution Strategy :
1. Outline several solution Strategies, without
regard for constraints
2. Conduct a feasibility study for each strategy.
3. Recommend a solution strategy, indicating
why other strategies were rejected
4. develop a list of properties for product
characteristics.
Planning the Development Process :

1. Define a life-cycle model and an organizational structure for the

project.
2. Plan the configuration management, quality assurance, and
validation activities.
3. Determine phase-dependent tools, techniques, and notations
to be used.
4. Establish preliminary cost estimates for system development.
5. Establishment preliminary development schedule.
6. Establish preliminary staffing estimates.
7. Develop preliminary estimates of the computing resources
required to operate and maintain the system.
8. Prepare a glossary of terms.
9. Identify sources of information, and refer to them throughout
the project plan.
 2.3.2 Milestones, Documents, and Reviews
• Improve product visibility to the developer during development time.
• This improve
• product quality,
• Increased programmer productivity
• Better morale among team members.
• The following presents typical documents, project mile stones, reviews and
sign-offs used in Phased Life Cycle Model.
1. System Definition and Project Plan :
• Product Feasibility Review :
• determine feasibility of project continuation
• Decides termination, redirection or continuation of the project.
2. Users Manual :
• Provides a vehicle of communication between customer and developer.
• Prepared using system definition.
• This is part of Product Requirement Specification.
• Outline of users manual
Section 1: Introduction
• Product overview and rationale
• Terminology and basic features
• Summary of display and report formats
• Outline of the manual
Section 2 :Getting started
• Sign-on
• Help mode
• Sample run
Section 3: Modes of operation
• Commands/dialogues/reports
Section 4: Advance features
Section 5: Command syntax and system options
3. S/W Requirement Specification:
• Clearly and precisely define essential requirements for the s/w
product.
• External interface to h/w, firmware, other s/w and people.

• Format of a Software Requirement Specification

Section 1: Product Overview and summary
Section 2: Development/operations/maintenance environment
Section 3: External interfaces and data flow
• User display/report formats
• User command summary
• High-level data flow diagram
• Logical data sources/sinks
• Logical data stores
• Logical data dictionary
Section 4: Functional Specifications
Section 5 : Performance requirements
Section 6: Exception conditions/exception handling
Section7 : Early subset and implementation priorities
Section 8 : Foreseeable modification and enhancements.
Section 9 : Acceptance criteria
• Functional and performance tests
• Documentation standards
Section 10: Design guidelines
Section 11: Sources of information
Section 12: Glossary of terms
4. S/W Verification Plan:
• Methods to be used and the results to be obtained in verifying each of the
requirements stated in the s/w product specification.
Section1 : Requirements to be verified.
Section 2: Design verification plan
Section 3: Source-code test plan
Section 4: Test completion criteria
Section 5: Document verification plan
Section 6: Tools and techniques to be used.
5. A s/w Requirements Review :
• To ensure the adequacy of the system definition, the
project plan, the s/w requirement specification, s/w
verification plan and the users manual.
• Attendees at the requirements review typically include
The planning and analysis team
Customer representatives
Representatives from the product development group
Quality assurance representatives.
• Goals are ensure
Everyone agrees on terminology.
Everyone interprets the specification in the same way
To expose the problems area.
• Number of peoples in review 3 or 4 to 10 or 12.
6. s/w design specification:
• 2 stages
i) Architectural design.
 document is created.
Preliminary review.
Data flow diagrams for the s/w product.
Conceptual layout of data structures and data bases.
Names, dimensional units and other attributes of data objects.
Name and functional description of each module.
Interface specification for each module.
Interconnection structure of modules
Interconnection among modules and data structures.
Timing constraints
Exception conditions.
ii) Detailed design
• Physical layout of data structures and data bases.
• Data dictionary specifications.
• Detailed algorithm for each new module to be
written.
• Adaptation required for existing code that will be
reused.
• specific programming techniques required to
solve unique problem.
• Initialization problem.
• Legality check and exception.
• Packaging of module into pyhsical implemention.
7. s/w product specification :
• Evaluate the adequacy of the architectural
design.
• More than one review required to solve
problem.
• A formal sign-off is required of the project
manager.
8. s/w design specification:
• Determine the acceptability of the s/w design
specification.
• A formal sign-off is required of the project
manager.
9. s/w Verification Plan :
• Include methods to verify the design is complete
and consistent with respect to the requirements.
• Also verify that the source code is complete and
consistent with respect to the requirement and
design specification.
10. Acceptance Test Plan:
• Includes the
actual test cases.
Expected results
Capabilities to be demonstrated by each test.
• Format
• section
• Format
Section 1: Requirements to be verified.
Section 2: Test cases for each requirement.
Section 3: Expected outcome of each test case.
Section 4: capabilities demonstrated by each test.
During Implementation Phase
11. Source code is written
• Debugged
• Unit tested
• Observing standard practices on
• Logical structure
• Coding /style.
• Data Layout.
• Comments.
• Debugging .
• Unit testing.
12. Source code Reviews:
• Ensure all code has been reviewed one person other than
programmer.
• A form sign-off is required of the reviewer.
During product Evolution:
13. Work product Audit:
• Inspections and walkthrough are conducted.
 Verify the completeness, consistency and suitability
• Work product audit include
 Requirement specification
 Design document
 Source code
 Test cases
Conduct by Quality assurance group.
14. (i)The Installation and Training Plan
• Simple or quite involved
• Adequate time and resource allocated in the
development schedule.
(ii). s/w Maintenance Plan:
• May or may not be a contractual responsibility
• Some cases development organization produces
maintenance plan
• Some cases customer develop the maintenance
plan.
Prior to Product Delivery
15. s/w Verification Summary:
• Conducts Final Acceptance Review
• Confirms that all requirements specified have
been met.
• Verify
 The source code.
 External documents are complete
 Consistent
 Ready for delivery.
 Sign-off with developer and customer
16.Project Legacy:
• Summarizes the project
• Provide record of
 What went well
 What went wrong
• Format :
Section 1: project Description
Section 2: Initial Expectations
Section 3: Current Status of the Project
Section 4: Remaining areas of concern.
Section 5: Activities/Time log
Section 6: Technical lessons learned
Section 7: Managerial lessons learned.
Section 8: Recommendations for future Projects.
 REVIW WORK PRODUCTS REVIEWED
PFR Product Feasibility Review System Definition
Project Plan

SRR Software Requirements s/w requirement specifications

Review Preliminary users manual
Preliminary verification Plan
PDR Preliminary Design Review Architectural Design Document

CDR Critical Design Review Detailed design specification

Users manual
s/w verification plan
SCR Source Code Review Walkthrough and implementation of
source code

ATR Acceptance Test Review Acceptance

PRR Product Release Review All of the above

PPM Project Post Mortem Project legacy.

 2.3.3 Cost Model
• s/w life cycle can be obtained by considering
• The cost of performing the various activities.
• Cos of conducting a s/w project is
• The sum of the cost incurred in conducting each phase of the
project.
• Cost incurred with in each phase include
• The cost of performing the process and preparing the products for
that phase
• The cost of verifying that the products of the present phase are
complete and consistent with respect to all previous phase.
• Modification and corrections to the products of previous
phases are necessary because the process of the current
phase will expose
• Inaccuracies,
• Inconsistencies
• Incompleteness
in those products, changes in customer requirements,
schedules, priorities and budget will dictate modifications.
Cost of system definition and the project plan :
• Cost of performing the planning function
• Preparing the documents
• Cost of verifying system definition accurately states the
customer needs
• The cost of verifying the project plan feasible.
1. S/w requirement specification cost
• Cost of performing requirements definition and
• Preparing the specification document
• Cost of modifying and correcting the system definition and the project
plan
• Cost of verifying the design against the requirements, system definition
and project plan.
2. Design Cost:
• Cost of performing the design activities
• Preparing the
• Design specification and
• Test plan plus
• The cost of modifying and correcting the system definition, the project
plan and the s/w requirement specification plus
• The cost of verifying the design against the requirements the system
definition, and the project plan.
3. Product Implementation Cost :
• Cost of
• Implementing
• Documenting
• Debugging
• Unit testing the source code plus
• Cost of completing the users manual.
• The verification plan.
• The maintenance procedure.
• Installation and training instruction. Plus
• The cost of modifying and correcting the system specification
and verification plan. Plus
• The cost of verifying that the implementation is
• Complete
• Consistent and
• Suitable with respect to system definition and s/w requirement specification
and design the documents.
4. System Testing cost:
• Cost of planning and conducting tests
• The cost of modifying and correcting the source code and
external documents
• The cost of verifying that the tests adequate validate the
product.
5. Maintenance Cost:
• Sum of cost of performing product enhancements
• Making adaptations to new processing requirements and
• Fixing Bugs
 2.3.4 Prototype Life-Cycle Model
• Emphasizes the sources of
product request,
The major go/no-go decision points
Use of prototypes.
• Prototype
Is a mock-up model of s/w product
Includes components of actual product.
Exhibits limited
 Functional capabilities
Low reliability
Inefficient performance.
• Reason for developing prototype
1.Illustrate
i/p data formats
Messages
Reports
Interactive dialogues
2. Explore technical issues
• Best and only way to resolve the issues related to design
decision, depends on
– The response time of a device controller or
– The efficiency of a sorting algorithm.
3. Phased model is not appropriate
• In situations where the phased model of
analysis -> design -> implementation is not appropriate.
• It is applicable when it is possible to write complete
set of specifications for the product at the beginning of
the life cycle.
• New versions of existing product using this.
• Totally new product will involve some prototyping
during the planning and analysis phase.
 2.3.5 Successive Versions
• Product may be developed by iterating
through a series of successive designs and
implementations.
• Each successive version of the product is a
functioning system capable of performing
useful work.
Planning &
Analysis

Design version
I

Build Version

Assess Version
I

No
Good

Main
2.4 planning an organizational structure

• Tasks in life time of a s/w products are

• Planning
• Product development
• Services
• Publications
• Quality assurance
• support
• Maintenance
 2.4.1 Project Structure
• Project format :
• Assembling a team of programmers who conduct a project from
start to finish.
• Project team members do
• product definition
• design the product
• implement it
• test it
• conduct project reviews and
• prepare the supporting documents.
• Some team members participate in installation and
maintenance.
• Some may go to new projects
• Work on project 1 to 3 yrs.
• Functional Format :
• Different team programmers performs each phase of
the project.
• Work products pass from team to team.

• Matrix Format
• Each of the function has its own management team and
group of specialized persons.
• Each project has a project manager concerned only
with that project.
• Each functional group participate in that project.
• Everyone has at least 2 bosses.
 2.4.2 Programming Team Structure

1. Democratic teams:
• Developed by weinberg as “Egoless team”.
• Ego less Team:
Group leadership rotate from member to member based
on differing abilities of team members.
Work products discussed openly and freely by all.
• Democratic Team:
 One team member designated team leader.
 Team leader does not rotate.
 One individual is responsible for coordination.
 Structure Communication Path

• Advantage:
• Opportunity for each team member to contribute to decision.
• Opportunity for team members to learn from one other.
• Increased job satisfaction
• Non threatening work environment.
• Manteri suggest – well suited to difficult, long-term research
and development projects
• Team stay together for several years and work on different
projects.
• Disadvantages:
• Communication overhead to reach decision.
• Requirement to work together .
• Weakening individual responsibility and authority.
2. Chief Programmer Teams:
• Highly structured
• The management structure and communication paths are used.
• The chief programmer
• designs the product.
• Implements critical parts of the product
• Makes all major technical decisions.
• Work is allocated to the individual programmer.
• Programmer:
• Write code and debug, document and unit test it.
• The back-up programmer:
• Serves as consultant to the chief programmer on various technical problems.
• Chief programmer assisted by administrative program manger.
• Responsibility and authority for development of s/w product.
• Advantageous:
• Centralized decision making and reduced communication paths

Structure Communication Path

chief programmer

Librarian
programmer
back-up programmer
3. Hierarchical Team Structure:
• Between extremes of democratic and chief
programmer.
• Project Leader:
• Assign Tasks
• Attend Reviews
• Walk through
• Detects problem Area
• Balances the work load
• Participate in technical activities.
• Limits the number of communication paths.
• Well suited for hierarchical s/w products
• Each sub system assigned to different team
• Disadvantageous:
• Most technically competent programmers tend to
be promote into management positions.
• Loosing a good programmer.
 2.4.3 Management Objectives

• A related technique .
• Employees set their own goals and objectives
with the help of their supervisor
• Participate in the setting of their supervisors
goal.
• Evaluated by meeting concrete, written
objectives.
• Tangible , clearly achievable objectives are set
for periods of 1 to 3 months.
• Well suited
• To the milestones and intermediate work products of s/w
engineering.
• To the temperament of highly skilled and self motivated
s/w engineers.
• MBO can be applied at all levels of an organization
• Can include both product-oriented objectives.
• Completion of design
• Testing
• Self-improvement objectives
• Skills to acquire and preparation for advancements
• Job oriented skills and career oriented goals are agreed by
supervisor and subroutine.
• Placed in writing
• Evaluated at the end of an agreed-upon time period.
 2.5 other planning Activities
• Includes the planning
The configuration management
Quality assurance functions
Planning for independent validation and
verification.
Planning phase-dependent tools and
techniques.
• 2.5.1 planning for configuration Management
and Quality Assurance:
Configuration management concerned with
 controlling changes in work product.
Accounting for status of work products
Maintaining the program support library
Quality Assurance
Develops and monitors adherence to project standard
Perform audits of the process and work products
Develops and performs the acceptance tests.
2.5.2 Planning for Independent Verification and
Validation:
• On some critical s/w projects
Independent organization may provide
verification and validation .
Verification ensures various work products
are complete and consistent with respect
other work product.
 validation involves planning and execution
of test cases
2.5.3 Planning Phase-Dependent Tools and
Techniques:
• Automated tools
• Specialized Notations
• Modern techniques used to develop s/w
requirement specifications
• Architectural and detailed design source code
• Automated testing may be used for unit testing,
system testing and acceptance testing
• Management tools such as PERT charts, Gant charts,
work break down structure, personnel staffing
charts may be used to track and control progress
2.5.4 Other Planning Activities:
• Includes preparing
preliminary cost estimates for product
development.
Establishing a preliminary development
schedule
Establishing preliminary staffing levels
Developing preliminary estimates of the
computing resources and personnel
required to operate and maintain the
system.