SOFTWARE ENGINEERING Sharon Dominick,

Assistant Professor,
Department of Computer Applications,
UNIT 1 Bishop Heber College,
Trichy.
INTRODUCTION
“The practical application of scientific knowledge to the design and
construction of computer programs and the associated documentation required
to develop, operate and maintain them.”
-Boehm
“The systematic approach to the development, operation, maintenance and
retirement of software”
-IEEE
Software engineering is the technological and managerial discipline concerned
with systematic production and maintenance of software products that are
developed and modified on time and within cost estimates.
DEFINITIONS
Programmer
- denotes an individual who is concerned with the details of implementing,
packaging and modifying algorithms and data structures written in particular
programming languages.
Computer software/computer program/source code/software product
- includes the source code and associated documents and documentation that
constitute a software product.
Documentation
- explains the characteristics of a document.
Internal Documentation
- describes the characteristics of the code.
External Documentation
- explains the characteristics of the document associated with the code.
Customer
- denotes an individual or organization that initiates procurement or modification of a
software product.
Software reliability
-the ability of a program to perform a required function under stated conditions for
a stated period of time.
SIZE FACTORS
Here the focus is on the level of effort devoted to software development and
maintenance.
1. Total effort devoted to software
2. Distribution of effort
3. Project size categories
4. How programmers spend their time.
1.TOTAL EFFORT DEVOTED TO SOFTWARE
The total amount spent on computing in US in 1980 is estimated as about $130
billion(5% of Gross National Product).
Computing revenues would be 8% by 1985 & 12.5% by 1990.
It is estimated that demand will exceed supply by750,000 to 200,000 people by
1990.
In 1960,ratio was 80% hardware cost to 20% software cost.
By 1980, the ratio reversed,20% hardware cost to 80%software cost.
By 1990 software costs for 90% of amount spent on computing.
2.DISTRIBUTION OF EFFORT
The lifespan for a software product is :
1 to 3 years in Development
5 to 15 years in use(maintenance)
The distribution of effort between development and maintenance is 40/60,30/70,even
10/90
Software maintenance involves 3 types of activities:
 Enhancing the capabilities of the product
 Adapting the product to new processing environments
 Correcting bugs
The distribution of maintenance effort for
 enhancement is 60%
 Adaptation is 20%
 Correction is 20%
During development phase of software product the distribution of effort is
40% analysis and design
20% implementation
40% integration and acceptance testing

Relative
effort

16% 8% 16% 36% 12%

12%
Analyz Implemen Test Enhanc Fix
Adapt
e and t e
design

Distribution of effort in Software Lifecycle

3 PROJECT SIZE CATEGORIES
Category No of Duration Product size
programmers
Trivial 1 1-4 weeks 500 source lines(packaged in
(personal s/w) 10 to 20 subroutines)

Small (scientific,commercial apps) 1 1-6 months 1K-2K(25 to 50 routines)

Medium 2-5 1-2 years 5K-50K(250 to 1000

(assemblers, MIS,inventory,process control routines)
apps)

Large 5-20 2-3 years 50K-100K(several

(comilers, time sharing sys,db subsystems)
packages,graphics sys, real time control sys)
Very Large(OS, databse systems, military and 100-1000 4-5 years 1M(several major subsystems)
control sys)
Extremely large(air traffic control,ballistic 2000-5000 5-10 years 1M-10M(very large
missile defence, military and command control subsystems)
sys)
4. HOW PROGRAMMERS SPEND THEIR TIME?
Writing programs 13%
Reading programs and manuals 16%
Job Communication 32%
Personal 13%
Miscellenous 15%
Training 6%
Mail 5%
QUALITY AND PRODUCTIVITY FACTORS
Individual ability
Team communication
Product Complexity
Appropriate notations
Systematic approaches
Change control
Level of technology
Required reliability
Available time
Problem understanding
Stability of requirements
Required skills
Facilities and resources
Adequacy of training
Management skills
Appropriate goals
Rising expectations
MANAGERIAL ISSUES
Technical and managerial activities are equally important to the success of the
software project.
Some problems identified by respondents as management problems are:
1. Planning for s/w engineering projects is generally poor.
2. Procedures and techniques for selecting project managers is poor.
3. The accountability of many s/w engineering projects is poor, it leaves the question
who is responsible for various project functions.
4. The ability to accurately estimate the required resources in project development is
poor.
5. Success criteria for software development projects are inappropriate.
6. Decision rules to aid in selecting proper organizational structure is not available.
7. Decision rules for selecting correct management techniques are not available.
8. Procedures, methods and techniques for designing a project control system are not
readily available.
9. Procedures, techniques and strategies that provide visibility of progress to project
managers are not available.
10. Standards and techniques for measuring quality of performance and data
processing analysts are not available.
Some methods for solving the problems were:
1.Educate and train top management, project managers and sw developers.
2.Enforce the use of standards, procedures and documentation.
3.Analyze data from prior software projects to determine effective methods.
4.Define objectives in terms of quality desire.
5.Define quality in terms of deliverables.
6.Establish success priority criteria.
7.Allow for contingencies.
8.Develop truthful, accurate cost and schedule estimates that are accepted.
9.Select project managers based on ability to manage software projects,rather than
technical ability or availability.
10.Make specific work assignments to software developers and apply job
performance standards.
PLANNING A SOFTWARE PROJECT Chapter 2
DEFINING THE PROBLEM
1. Develop a definitive statement of the problem to be solved. Include a
description of the present situation, problem constraints and a statement of
goals to be achieved.
2. Justify a computerized solution strategy for the problem.
3. Identify the functions to be provided by and the constraints on h/w, s/w
and people.
4. Determine system level goals and requirements for the development
process and work products.
5. Establish high level acceptance criteria for the system
DEVELOPING A SOLUTION STRATEGY
6. Outline several solution strategies without regard for constraints.
7. Conduct a feasibility study for each strategy.
8. Recommend a solution strategy, indicating why other strategies were
rejected.
9. Develop a list of priorities for product characteristics
PLANNING THE DEVELOPMENT PROCESS
10. Define a life cycle model and an organizational structure for the project.
11. Plan the configuration management, quality assurance and validation activites.
12. Determine phase dependent tools, techniques and notations to be used.
13. Establish preliminary cost estimates for system development.
14. Establish a preliminary development schedule.
15. Establish preliminary staffing estimates.
16. Develop preliminary estimates of the computing resources required to operate and
maintain the system.
17. Prepare a glossary of terms.
18. Identify sources of information, and refer to them throughout the project plan.
DEFINING THE PROBLEM
First step is to prepare a concise statement of problem to be solved and constraints
that exist for a solution.
The problem statement should include:
 Description of the present situation
 Goals to be achieved by the new system.

Problem definition requires thorough understanding of the problem domain and

environment.
Techniques for gaining knowledge are:
 Customer interviews
 Observation of problem tasks
 Actual performance of the tasks by the planner
GOALS AND REQUIREMENTS
Goal is a concise statement of the problem and an indication of the constraints that
exist for its solution.
Goals apply to both the development process and the work products.
They can be qualitative or quantitative.
Quantitative: the system should be delivered within 12 months.
Qualitative: the system should make users job more interesting.
Some goals may apply to all projects.
Ex: every s/w product should be useful, reliable, understandable and cost effective.
Requirements specify capabilities that a system must provide in order to solve a
problem.
They include
 Functional requirements
 Performance requirements
 Requirements for hardware, software and user interfaces
Quantitative:
Phase accuracy shall be within 0.5 degrees
Response to external interrupts shall be 0.25 second maximum.

Qualitative:
Accuracy shall be sufficient to support the mission.
System shall provide real time response.
Portability
The ease with which software can be transferred from one computer system or
environment to another.
Reliability
The ability of the program to perform a required function under stated conditions for
a period of time.
Efficiency
The extent to which software performs its intended functions with a minimum
consumption of computing resources.
Accuracy
A Qualitative assessment of freedom from error.
A quantitative measure of magnitude of error, expressed as a function of the relative
error.
Error
A discrepancy between a computed value or condition and the true, specified or
theoretically correct value or condition.
Robustness
The extent to which software can continue to operate correctly despite the
introduction of invalid inputs.
Correctness
The extent to which software is free from design defects and from coding defects,
that is fault free.
The extent to which software meets its specified requirements
The extent to which software meets user expectations.
FACTORS TO BE CONSIDERED IN PROJECT
PLANNING
•Estimation techniques to be used, accuracy required.
•Life cycle model, control functions, reviews.
•Organizational structure.
•Level of formality in specifications, test plans
•Level of verification and validation.
•Level of configuration management required.
•Follow on maintenance responsibilities.
•Tools to be developed and used.
•Personnel requirement and training.
FACTORS IN SETTING PROJECT GOALS
•New capabilities to be provided
•Old capabilities to be preserved /enhanced
•Level of user sophistication
•Efficiency requirements
•Reliability requirements
•Likely modifications
•Early subsets and implementation priorities
•Portability requirements
•Security concerns
PLANNING THE DEVELOPMENT PROCESS
Planning involves several considerations.
Initially define a product life cycle model.
The software life cycle encompasses all activities required to define, develop, test
deliver, operate and maintain a software product.
Models
1. The Phased Life cycle model
2. The Cost model
3. The prototype model
4. The successive iterations model
THE PHASED LIFE CYCLE MODEL
This model segments the software life cycle into a series of successive activities.
Each phase requires well defined input and uses well defined processes and results in
well defined products.
Resources are required to complete processes in each stage. Each phase is a
accomplished by applying explicit methods, tools and techniques.
The phased model consists of analysis, design, implementation, system testing and
maintenance. This model is also called the waterfall chart.
 FORMAT OF SYSTEM DESIGN
Section 1: Problem definition
Section 2: System justification
Section 3: Goals for the system and the project
Section 4: Constraints on the system and the
project
Section 5: Functions to be provided(h/w, s/w,
people)
Section 6: User characteristics
Section 7:
Development/operating/maintenance
environments
Section 8: Solution strategy
Section 9: Priorities for system features
Section 10: System acceptance criteria
Section 11: Sources of information
Section 12: Glossary of terms
FORMAT OF THE PROJECT PLAN
Section1: Life cycle model/terminology/milestones/work products
Section2: Organization Structure/Management structure/Team structure/work
breakdown structure/ statements of work
Section3: Preliminary staffing and resource requirements staffing and resource
schedule.
Section4:Preliminary development schedule/PERT Network/Gantt charts
Section5:Preliminary cost estimate
Section6:Project monitoring and control mechanisms
Section7:Tools and techniques to be used
Section8:Programming languages
Section9:Testing requirements
Section10:Supporting documents required
Section11:Manner of demonstration and delivery
Section12:Training schedule and materials
Section 13:Installation plan
Section14:Maintenace considerations
Section15:Method and time of delivery
Section 16:Method and time of payment
Section17:Sources of information
 Design Phase Implement Phase System Test Maintenance
Analysis Phase
Phase

Planning
Requirements Definition
MILESTONES, DOCUMENTS AND REVIEWS
As the software product evolves through the development phase, it becomes difficult
and impossible for the project managers & team members to asses it.
Its difficult to :
❑ asses progress
❑ determined resources expended
❑ predict schedule delays
❑ anticipate problem areas
The terminology that is adapted from IEEE standard for software quality assurance
plans:
1. The system definition and project plan are prepared
2. The preliminary version of users manual is prepared.
3. A software requirement specification is prepared.
4. A preliminary version of software verification plan is prepared.
5. A software requirements review is held.
6.The design team creates the software design specification in 2 stages.(architectural
design followed by PDR)
7.A preliminary design review is conducted to evaluate the software product
specification.
8.Folloiwng design, the critical design review is held.
9.During design, the software verification plan is expanded to include methods used
to verify the design completion.
10.Software verification review is held to check completeness and review acceptance
test plan.
11.During implementation source code is written, debugged and tested with standard
practices.
12.During implementation source code reviews are held.
13.During product evolution, inspections and walkthroughs are conducted to verify the
completeness, consistency and suitability of the work products.
14. The users manual, the installation and training plans, maintenance plans are
completed during implementation phase.
15.Prior to product delivery a final acceptance review is performed.
16.Finally a project legacy is written.
OUTLINE OF THE USERS MANUAL
Section 1 Introduction
Product overview and rationale
Terminology and basic features
Summary of display and report formats
Outline of the manual
Section2 Getting started
Sign on
Help mode
Sample run
Section3 Modes of operation
Commands/dialouges/reports
Section4 Advanced features
Section5 Command syntax and system options
FORMAT OF A SOFTWARE REQUIREMENT
SPECIFICATION
Section1:Product overview and summary
Section2:Development/operations/maintenance environments
Section3:External interfaces and data flow
User displays/report formats
User command summary
High level data flow diagrams
Logical data sources/sinks
Logical data stores
Logical data dictionary
Section4:Functional specifications
Section5:Performance requirements
Section6:Exception conditions/exception handling
Section7:Early subsets and implementation priorities
Section 8: Foreseeable modifications and enhancements
Section9:Acceptance criteria
Functional and performance tests
Documentation standards
Section10:Design guidelines
Section11:Sources of information
Section12:Glossary of terms
OUTLINE OF SOFTWARE VERIFICATION PLAN
Section1:Requirements to be verified
Section2: Design verification plan
Section3:Source code test plan
Section4: Test completion criteria
Section5: Document verification plan
Section6: Tools and techniques to be used
CONTENT OF AN ARCHITECTURAL DESIGN
SPECIFICATION
❖Data flow diagrams for the software 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 specifications for each module
❖Interconnection structure of the modules
❖Interconnections among modules and data structures
❖Timing constraints
❖Exception constraints
CONTENT OF A DETAILED DESIGN SPECIFICATION
❖Physical layout of the data structures and data bases
❖Data dictionary specification of all concrete data objects
❖Detailed algorithms for each new module to be written
❖Adaptations required for existing code that will be reused
❖Specific programming techniques required to solve unique problems
❖Initialization procedures
❖Legality checks and exception handling
❖Packaging of modules into the physical implementation
FORMAT OF AN ACCEPTANCE TEST PLAN
Section1: Requirements to be verified.
Section2: Test cases for each requirement
Section3: Expected outcome of each test case
Section4: Capabilities demonstrated by each test
FORMAT OF PROJECT LEGACY
Section1: project description
Section2: initial expectations
Section3: current status of the project
Section4: remaining areas of concern
Section5 : activities/time log
Section6: technical lessons learned
Section7: managerial lessons learned
Section8: recommendations for future projects
THE COST MODEL
The cost of conducting a software project is the sum of costs incurred in conducting
each phase of the project.
The costs incurred includes:
❖the cost of performing the phases
❖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
THE PROTOTYPE LIFE CYCLE MODEL
A prototype is a mockup or model of the software product.
It incorporates components of the actual product.
It exhibits limited fuctional capabilities, low reliability and/or inefficient performance.
Reasons for developing a prototype:
❖To illustrate input data formats, messages, reports and interactive dialogues
❖To explore the technical issues in the proposed product.
❖ In situations where the model of analysis, design and implementation is not
appropriate.
SUCCESSIVE VERSIONS
Product development by the method of successive versions is an
extension of the prototyping in which an initial skeleton is refined
into increasing levels of capability.
Here each successive version of the product is a functional system
capable of performing useful work.
PLANNING THE ORGANIZATIONAL
STRUCTURE
PROJECT STRUCTURE
❖Project format
-involves assembling a team of programmers who conduct a project from start to
finish.
- the team defines, designs, implements, tests it and conducts project reviews and
prepares supporting documents.
-team members may work on the project for 1 to 3 years and are assigned to new
projects after completion of the current one.
❖Functional format
-Different teams of programmers perform each phase of the project.
-The work products pass on from one team to another as they evolve.
-The planning and analysis team develops system definition and project plan and
passes the document to the project definition team who designs the product with the
SRS.
-An implementation team implements, debugs, tests and passes it to a system testing
team.
-Finally a quality assurance team certifies the quality of all work products.
-Functional format involves 3 teams: analysis,design and implementation, testing and
maintenance team.
-It requires more communication among teams than project format.
❖Matrix format
-In this format, each of the functions has its own management team and a group of
specialist personnel.
-The development project has a project manager concerned only with that project.
-The project manager generates and reviews documentation and may participate in
design, implementation and testing.
-Each functional group participates in each project.
PROGRAMMING TEAM STRUCTURE
Every programming team has an internal structure.
The team structure depends on the nature of the project and the
product.
Basic team structure includes:
❖Democratic teams
❖Chief programmer teams
❖Hierarchical team structure
DEMOCRATIC TEAMS
It is also described as the “ego less team”.
The management structure and communication paths are illustrated
in the diagram.
Here the goals are set and the decisions are made by group
consensus.
Group leadership rotates from member to member based on the
tasks to be performed.
Work products are discussed openly and freely examined by all
team members.
CHIEF PROGRAMMER TEAMS
They are highly structured.
The chief programmer assigns the product, implements critical parts of the
product and makes all major technical decisions.
Work is allotted to individual programmers by the chief programmer.
The program librarian maintains program listings, design documents, test
plans etc in a central location in the batch environment.
The backup programmer is a consultant to the chief programmer
regarding technical problems.
The chief is assisted by administrative program manager who does
administrative details.
HIERARCHICAL TEAM STRUCTURE
Large projects often distinguish levels of management:
 Leaf nodes is where most development gets done; rest of tree is
management
 Different levels do different kinds of work—a good programmer may not be
a good manager
 Status and rewards depend on your level in the organization
 Works well when projects have high degree of certainty, stability and
repetition
 But tends to produce overly positive reports on project progress, e.g.:
 Bottom level: “We are having severe trouble implementing module X.”
 Level 1: “There are some problems with module X.”
 Level 2: “Progress is steady; I do not foresee any real problems.”
 Top: “Everything is proceeding according to our plan.”
OTHER PLANNING ACTIVITIES
It includes:
❖Planning for configuration management and quality assurance
❖Planning for independent verification and validation
❖Planning phase dependent tools and techniques
❖Other planning activities
PLANNING FOR CONFIGURATION MANAGEMENT
AND QUALITY ASSURANCE
Configuration management is concerned with:
•controlling changes in work products
•Accounting for the status of the work
•Maintaining the program support library
Quality assurance develops and monitors :
•Adherence to project standards
•Performs audits of the processes and work products
•Develops and performs acceptance test.
PLANNING FOR INDEPENDENT VERIFICATION AND
VALIDATION
Verification ensures that work products are complete and consistent with respect to
other work products and customer needs.
An external organization might verify that the design and specifications are complete
and consistent w.r.to system definition and the software product specifications.
Validation is concerned with assessing the quality of the software system in its actual
operating environment.
PLANNING PHASE DEPENDENT TOOLS AND
TECHNIQUES
Automated tools , specialized notations and modern techniques are used to develop
SRS, architectectural design and detailed designs and the source code.
Automated tools are used for unit testing, system testing, acceptance testing.
Management tools like PERT charts, Gantt chars and work breakdown structure,
personal staffing charts are used to track and control progress.
OTHER PLANNING ACTIVITIES
It includes:
❖preparing preliminary cost estimates for product development
❖Establishing a preliminary development schedule
❖Establishing preliminary staffing levels
❖Developing estimates of the computing resources
❖Personnel required to operate and maintain the system