1.

1 Introduction
(Software Engineering Process Paradigms, Process Models – Incremental and Evolutionary Models)

What is Software Engineering?

• Software engineering discusses systematic and cost-effective techniques for software development
• These techniques help develop software using an engineering approach
• Software engineering is the application of a systematic, disciplined, quantifiable approach to the
development, operation and maintenance of software, that is the application of engineering to
software

The Software Process:

• A process is a collection of activities, actions and tasks that are performed when some work product
is to be created
• An activity strives to achieve a broad objective and is applied regardless of the application domain,
size of the project, complexity of the effort, or degree of rigor with which software engineering is to
be applied
• An action encompasses a set of tasks that produce a major work product
• A task focuses on a small, well-defined objective that produces a tangible outcome
• A process framework establishes the foundation for a complete software engineering process by
identifying a small number of framework activities that are applicable to all software projects,
regardless of their size or complexity
• The process framework encompasses a set of umbrella activities that are applicable across the
entire software process
• Generic process framework activities:
o Communication: communicate & collaborate with customer/stakeholder to understand
objectives and requirements of the project
o Planning: software project plan defines the SE work by describing the technical tasks to be
conducted, possible risks, resources required, products to be produced and work schedule
o Modeling: create models for better understanding of software requirements and design
o Construction: code generation and testing required to uncover errors in the code
o Deployment: software delivered to customer - evaluates the product and provides feedback
• These framework activities are applied iteratively as project progresses
• Umbrella activities:
o Software project tracking & control: assesses progress against project plan and takes
necessary action to maintain schedule
o Risk Management: assesses risks affecting the outcome
of project or quality of product
o Software quality assurance: defines and conducts the
activities required to ensure quality
o Technical reviews: assesses products to uncover and
remove errors before next activity
o Measurement: defines and collects process, project and
project measures
o Software configuration management: manages effects
of change throughout the process
o Reusability management: defines criteria for work
product reuse and establishes mechanisms to achieve
reusable components
o Work product preparation & production: encompasses
the activities required to create work products such as
models, documents, logs, forms, lists
Exploratory Style of Software Development (build and fix programming):
• Informal development style: programmer makes use of his own intuition to develop a program
• Gives complete freedom to the programmer to choose the activities to develop software
• Development starts based on an initial briefing from the customer
• The software is tested and bugs are found and fixed
• Development + testing cycle continues till customer is satisfied
• Suitable for development of small programs only
• Shortcomings: exponential growth, unmaintainable code (unstructured & poor quality), difficult in
team development environments (no proper design or documentation)
• SE principles: abstraction & decomposition – solve problems due to human cognitive limitations

Break down
after size of
program
increases
beyond
certain
value.

Abstraction (modelling or model construction):

• The simplification of a problem by focusing on only one aspect of the problem while omitting all
other aspects
• Construction of a simpler version of a problem by ignoring the details

Decomposition (divide & conquer):

• Decompose the problem into many small independent parts each solved separately one at a time
• Each small part is easy to grasp and understand and can be easily solved
• The full problem is solved when all the parts are solved
• Used to contain the exponential growth of the perceived problem complexity

Why study Software Engineering?

• The skill to participate in development of large software
• Learn how to efficiently handle complexity in a software development problem
• Learn techniques of SRS, UI development, quality assurance, testing, project management,
maintenance

Control Flow Based Design:

• Indicates the sequence in which the program’s instructions are executed
• In order to develop programs having good control flow structure, flow charting
technique is developed
• Helps understand how the output is produced from the input values

Structural Programming:
• No GOTO or JUMP statements – control structure becomes messy
• Only 3 programming constructs: sequence, selection, iteration
• A program is called structure when it uses only these 3 types of constructs and is modular
• Modular program - decomposed into a set of modules with low interdependency among each other
• Advantage: less error-prone, more readable, easier to maintain, less effort to develop
Data Structure Oriented Design:
• ICs can be used to solve more complex problems
• First a program’s data structures are designed using notations for sequence, selection, iteration
• The code structure is designed based on the data structure

Data Flow Oriented Design:

• VLSI circuits – computers faster and more powerful – further challenging problems
• The major data items handled by a system must be
identified and the processing required on these data
items to produce the desired outputs should be
determined
• The functions/processes and the data items that are
exchanged between the different functions are
represented by a data flow diagram (DFD)

Object Oriented Design (OOD):

• Natural objects (such as employees, pay-roll-register, etc) relevant to a problem are first identified
and then the relationships among the objects such as composition, reference and inheritance are
determined.
• Each object essentially acts as a data hiding/abstraction entity
• Simplicity
• Reuse possibilities
• Lower development time
• Lower development cost
• More robust code
• Easier maintenance

Software Life Cycle:

• Represents the series of identifiable stages through which it evolves during its life time
• Inception stage: request by customer(s), usually not clear about all features, vague description
• Then a software evolves through various stages/phases until it is fully developed and released to
customers
• Operation/Maintenance phase: users use the software, fix failures, improvements, modifications,
continually making changes – the longest phase
• Finally, software retired, not useful to users, discarded

Software Life Cycle Models:

• Also called software development life cycle (SDLC) and software development process model
• Graphically depicts the different phases through which a software evolves + textual description
• Process versus Methodology:
Process describes all or some activities (inception + maintenance + retirement) but methodology
describes steps to carry out a single or few individual activities

Why Model Life Cycle?

• Forms a common understanding of articles among software developers
• Helps identify inconsistencies, redundancies and emission in the development process
• Helps development of software in a systematic and disciplined manner
• Defines entry and exit criteria for every phase
• Monitors the progress of project
Phase Entry & Exit Criteria:
• Usually expressed as a set of conditions that needs to be satisfied for the phase to start/end
• Activities of a phase might stop prematurely or continue even after phase should have ended
• Project manager can’t determine the exact status of development or track the progress of project
• 99 per cent complete syndrome:
appears when project manager has no way of assessing the progress of the project, the optimistic
team members feel that their work is 99% complete even if it is far from completion

Classical Waterfall Model:

• Simple but idealistic
• Assumption: all requirements given initially only
• All other life cycle models can be thought of as extensions
of classical waterfall model
• Though not used for software development, it is implicitly
used while documenting software

Phases of Classical Waterfall Model:

• See the above figure
• Feasibility study to integration and system testing phases = development
phases
• After development, delivery to customer, start using, then
operation/maintenance phase
• Project management is an important activity in the life cycle and deals with
managing the software development and maintenance activities
1. Feasibility Study:
• Financially and technically feasible?
• Collect basic information: data items that are input to the system, processing required on this data,
output required and various constraints on the development. The collected data is analyzed:
o Development of an overall understanding of the problem:
§ What the customer requires to be developed? – only important requirements
§ Screen layouts required in GUI
§ Specific formulas or algorithms required
§ Databases schema to be used and ignored
o Formulation of the various possible strategies for solving the problem:
§ Various possible high-level solution schemes to the problem are determined
o Evaluation of the different solution strategies:
§ The solution schemes are analyzed to evaluate their benefits and shortcomings
§ Approximate estimates on resources required, cost & time required for development
§ Either the best solution is identified and next phase continues or none of the
solutions are feasible and the project is abandoned
2. Requirements Analysis and Specification:
• Aim: to understand the exact requirements of the customer and to document them properly
o Requirements gathering and analysis: (RG & RA)
§ Goal: to collect all relevant information from the customer to achieve the aim (RG)
§ Requirements are gathered from customer and analyzed
§ Goal: to weed out incompleteness and inconsistencies in the requirements (RA)
o Requirements Specification:
§ After RG & RA, the requirements are documented into an SRS
§ Written user end-user terminology hence understandable by the customer
§ Serves as a contract between the development team and the customer
§ Development activities and other documents are prepared based on it
3. Design:
• Goal: to transform the requirements specified in the SRS document into a structure that is suitable
for implementation in some programming language
• The software architecture is derived from the SRS. Two approaches:
o Procedural design / Traditional approach:
§ Based on data flow-oriented design
• Structured Analysis:
o Analysis of the requirement specification
o Detailed structure of problem is examined (DFD)
• Structured Design:
o Results of structured analysis are transformed into software design
§ Architectural / High-level design:
• Decomposing the system into modules
• Representing the interfaces & invocation relationships
among modules
§ Detailed / Low-level design:
• Internals of individual modules such as data structures
and algorithms of the module are designed &
documented
o Object oriented design approach:
§ Identify objects of the problem & solution domain and the relationship among them
§ Refer OOD (pg. 3)

4. Coding / Implementation and Unit Testing:

• Aim: to translate a software design into source code and to ensure that individually each function is
working correctly
• End-product of this phase is a set of program modules that have been individually unit tested
• Unit testing: designing test cases, testing, debugging to fix problems, and management of test cases

5. Integration and System Testing:

• Aim (integration): to verify that the interfaces among different units are working satisfactorily
• Aim (system): to ensure that the developed system conforms to the requirements in the SRS
• Different modules are integrated in a planned manner
• Integration of various modules are carried out incrementally over a number of steps
• During each integration, modules are partially integrated and the resultant system is tested
• System testing is carried out on the final fully working system. 3 activities involve:
o -testing: the system testing performed by the development team
o -testing: the system testing performed by a friendly set of customers
o Acceptance testing: after delivery, customer tests to determine to accept/reject it

6. Maintenance:
• Effort required more than the total effort of the development phases (Refer figure on pg. 4)
• Maintenance is required in the following three types of situations:
o Corrective maintenance: carried out to correct errors that were not discovered during the
product development phase
o Perfective maintenance: carried out to improve the performance of the system, or to
enhance the functionalities of the system based on customer’s requests
o Adaptive maintenance: required for porting the software to work in a new environment
(new computer platform or OS)
Shortcomings of the Classical Waterfall Model:
• No feedback paths – it is a sequential model
• Difficult to accommodate change requests
• Inefficient error corrections
• No overlapping of phases

Iterative Waterfall Model:

• Incorporating the necessary changes to the classical waterfall model
to make it usable in practical software development projects
• The main change is providing feedback paths from every phase to its preceding phases
• Feedback paths allow error correcting during some phase as and when detected

Phase Containment of Errors:

• The principle of detecting errors as close to their points of commitment as possible
• Early detection of bugs reduces the time and effort required for correcting them

Phase Overlap:
• Errors detected in later stages need to be corrected by reworking a previous phase
• Team members who complete their part of the work earlier than others may start working for the
next phase instead of sitting idle (blocking state) while others are working on the previous phase

Shortcomings of the Iterative Waterfall Model:

• Difficult to accommodate change requests
• Incremental delivery not supported
• Phase overlap not supported
• Error correction unduly expensive
• Limited customer interactions
• Heavy weight
• No support for risk handling and code reuse

Prototyping Model:
• Before development of the actual software, a working prototype of the system is built
• Prototype has limited functional capabilities, low reliability or inefficient performance
• Built using several shortcuts, it has inefficient, inaccurate or dummy functions

Necessity of the Prototyping Model:

• Advantageous for development of GUI part of an application, becomes easier to illustrate the input
data formats, messages, reports and interactive dialogs to the customer. Users can form an
opinion easily and we get a better understanding of the customers’ needs.
• Useful when the exact technical solutions are unclear to the
development team
• It is impossible to “get it right” the first time

Life Cycle Activities of Prototyping Model:

1. Prototype Development:
• Initial requirements gathering phase - quick design & a prototype is built
• Submitted for customer evaluation – based on feedback, requirements
are refined
• This cycle continues till customer approves the prototype
 2. Iterative Development:
• After approval, the actual software is developed using iterative waterfall approach
• Usually SRS is required, but here the requirements analysis and specification phase becomes
redundant since the working porotype serves as an animated requirements specification
• The code of the prototype is thrown away, but the experience helps a lot
• Cost of throwing the code is negligible than developing completely using iterative waterfall model

Strengths of the Prototyping Model:

• Most appropriate for projects that suffer from technical and requirements risks

Weaknesses of the Prototyping Model:

• Can increase the cost of development for projects that do not suffer from any risks
• Effective only for projects in which the risks can be identified upfront before development starts
• Ineffective for risks identified late during the development cycle

Incremental Development Model:

• Also known as the successive versions model
• Initially, a simple working system with few basic features is
delivered to the customer
• Desired system delivered over successive iterations

Life Cycle Activities of Incremental Development Model:

• Requirements broken down into several modules/features that can be incrementally constructed
• Planned number of iterations, hence easier to accommodate change requests from customers
• Core features developed first
• Non-core features require services from the core features
• Each incremental version (additional+refined features) is developed using iterative waterfall model
• At each version, customer feedback is obtained and incorporated in the next version

Advantages:
• Error reduction
• Incremental resource deployment

Evolutionary Model:
• Developed over a number of increments (riskier issues first)
• In incremental model, requirements gathered and SRS prepared initially only
• In evolutionary model, the requirements, plan, estimates and solution evolve over iterations
• Design a little - build a little - test a little - deploy a little model

Advantages:
• Effective elicitation of actual customer requirements
• Easy handling change requests

Disadvantages:
• Feature division into incremental parts can be non-trivial
• Ad-hoc design
Applicability of the Evolutionary Model:
• Easy to find modules for incremental implementation
• Customer prefers to receive product in increments to start using the features than waiting
• Projects using object-oriented development – easy to partition into standalone units (classes)

Rapid Application Development (RAD):

• Proposed to overcome the rigidity of the waterfall model to accommodate changes from customer
• Features of prototyping + waterfall model
• Prototypes are constructed and incrementally the features are developed and delivered
• Prototypes are enhanced and used instead of throwing away
• Major Goals of RAD:
o To decrease the time taken and the cost incurred to develop software systems
o To limit the costs of accommodating change requests
o To reduce the communication gap between the customer and the developers

Working of RAD:
• Plans are made for one increment at a time, time planned is called time box
• During each time box, a quick & dirty prototype style software for some functionality is developed
• Customer evaluates and based on feedback, the prototype is refined but prototype is not released
to the customer for regular use
• Development team (5-6 members) has a customer representative to bridge the gap

RAD accommodates change requests:

• Incorporation of change requests just after the delivery of an incremental feature saves cost as this
is carried out before large investments have been made in development and testing of a large
number of features

RAD provides faster development:

• Decrease in development time & cost and increased flexibility to accommodate changes:
o Minimal use of planning: gives flexibility to accommodate later requirement changes
o Heavy reuse of any existing code through rapid prototyping: reduced cost & faster
development

Applicability of RAD Model:

• Customized software
• Non-critical software
• Highly constrained project schedule
• Large software

Application characteristics that render RAD unsuitable:

• Generic products (wide distribution)
• Requirement of optimal performance and/or reliability
• Lack of similar products
• Monolithic entity

RAD vs. Prototyping Model:

• The code developed during prototype construction is usually thrown away
• In RAD, it is the developed prototype that evolves into the deliverable software
RAD vs. Iterative Waterfall Model:
• In iterative waterfall model, all functionalities of a software are developed together
• In RAD, the functionalities are developed incrementally through heavy code & design reuse
• RAD can easily accommodate changes based on customer feedback on the prototype
• Iterative model yields good quality documentation helpful during software maintenance
• Iterative model developed software usually has better quality & readability than RAD

RAD vs. Evolutionary Model:

• In RAD, each increment results in a quick and dirty prototype
• In evolutionary, each increment is systematically developed using iterative waterfall model
• In RAD, software is developed in much shorter increments than in evolutionary

Spiral Model:
• Number of loops can vary, each loop called a phase of the software process
• Project manager decides no. of phases depending on the project risks
• Spiral model can handle unforeseen risks that can show up much after project has started
• As opposed to prototyping model, here a prototype is made at the start of every phase, hence the
risk handling capabilities
• Radius of spiral represents cost incurred and angular dimension represents progress so far
• Each loop represents the waterfall model

Risk Handling in Spiral Model:

• Spiral model supports coping up with risks by providing the scope
to build a prototype at every phase of software development

Phases of the Spiral Model:

1. Quadrant 1 (Objective Setting):
• Objectives are investigated, elaborated and analyzed
• Risks involved are identified and alternative solutions are proposed

2. Quadrant 2 (Risk Analysis and Reduction):

• Alternative solutions are evaluated by developing an appropriate prototype to select the best

3. Quadrant 3 (Development and Validation):

• Develop and verify the next level of software
• Identified features are implemented and next version of software is available

4. Quadrant 4 (Review and Planning):

• Reviewing the results of the stages with the customer and planning the next version of software

Advantages & Disadvantages of the Spiral Model:

• Appears complex to follow to the developers because it is risk-driven and complicated in structure
• Hence, counterproductive to use unless staff is knowledgeable and experienced
• Most appropriate for projects having unknown risks that might show up later

Note: Read “A COMPARISON OF DIFFERENT LIFE CYCLE MODELS” from Rajib Mall
1.2 Introduction
(Typical Application of each model, Agile methodology, Process and Project Metrics)

Agile Development Models:

• Primarily designed to help a project adapt to change requests quickly
• Major aim is to facilitate quick project completion
• Agility is achieved by removing activities that may not be necessary for a specific project or wastes
time and effort

Agility Principles:
1. Our highest priority is to satisfy the customer through early & continuous delivery of valuable
software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the
customer’s competitive advantage.
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.

Scrum Model:
• Scrum principles are consistent with the agile manifesto and are used to guide development
activities within a process that incorporates the following framework activities:
o Requirements
o Analysis
o Design
o Evolution
o Delivery
• Within each framework activity, work tasks occur within a process pattern called sprint
• Work conducted within a sprint is
adapted to the problem at hand and
modified by the Scrum team
• No. of sprints for each activity varies as
per the product complexity & time
• Process patterns:
o Backlog
o Sprints
o Scrum meetings
o Demos
• Refer these process patterns from the
figure
Software Project Management:
Responsibilities of a Software Project Manager:
• Steering a project to success
• Ranges from invisible activities like building up team morale to highly visible customer
presentations
• Project proposal, writing, project cost estimation, scheduling, project staffing, software process
tailoring, project monitoring and control, software configuration management, risk management,
managerial report writing and presentation, and interfacing with clients
• 2 major types: Project planning & Project
monitoring and control

Project Planning:
• Undertaken and completed between feasibility
study & requirement analysis & specification
phases
• Planning project activities based on these estimates
• Initial plans are revised as the project progresses and gets more data
• All estimations and project plans are made on the basis of size (most fundamental parameter)
• If care not taken may result in schedule slippage causing customer dissatisfaction or project failure
o Estimation: estimate cost, duration and effort required to develop the product
o Scheduling: schedules for manpower and other resources are developed
o Staffing: staff organization and staffing plans are made
o Risk Management: risk identification, analysis and abatement planning
o Misc. Plans: quality assurance plan, configuration management plan

Project Monitoring and Control:

• Undertaken once development activities start
• Focus is to ensure that the software development proceeds as planned
• Project manager may sometimes change the plan as per situation

Metrics for Project Size Estimation:

• Project size is a measure of the problem complexity in terms of the effort and time required to
develop the product
• 2 metrics: Lines of Code (LOC) & Function Point (FP)

Lines of Code (LOC):

• Measure size of a project by counting the no. of source instructions in the developed program
• Comment lines and header lines are ignored
• Determining LOC at the beginning of a project is very difficult – involves systematic guessing
• Project manager divides the problem into modules, sub-modules and so on till the LOC of the leaf-
modules are small enough to be predicted
• Total size estimation is the total of all leaf-modules estimate

Approach:
• Using historical data or intuition, the planner estimates an optimistic (Sopt), most likely (Sm) and
pessimistic (Spess) value or count for each information domain value
• LOC S = (Sopt + 4Sm + Spess)/6
• From historical data, we have average productivity for the system of the project type, cost for a
person-month (a) and cost per line of the code (b)
• Effort = LOC/Productivity & Cost = LOC * b
Shortcomings of LOC:
• LOC is a measure of coding activity alone
• LOC count depends on the choice of specific instructions
• LOC measure correlates poorly with the quality and efficiency of the code
• LOC metric penalties use of higher-level programming languages and code reuse
• LOC metric measures the lexical complexity of a program and does not address the more important
issues of logical and structural complexities
• It is very difficult to accurately estimate LOC of the final program from problem specification

Function Point (FP):

• Overcomes many shortcomings of LOC
• It can easily be computed from the problem specification itself
• Idea: size of software product is directly dependent on the no. of different high-level
functions/features it supports (since it may require more effort)
• Estimate based on no. of inputs taken, outputs given and no. of files accessed by the function

FP Metric Computation:
• Step 1: Compute the unadjusted function point
(UFP) using heuristic expression
• Step 2: Refine UFP to reflect the actual complexities
of different parameters used in Step 1
• Step 3: Compute FP by further refining UFP to
account for the specific characteristics of the project
that can influence the entire development effort

Step 1: UFP Computation

• UFP = (No. of inputs)*4 + (No. of outputs)*5 + (No. of inquiries)*4 + (No. of files)*10 + (No. of
interfaces)*10
• No. of inputs: data item input by the user
• No. of outputs: related data items counted as 1-reports printed, screen outputs, error messages…
• No. of inquiries: a user command which only requires some action to be performed by the system
• No. of files: logical file-a group of related files-data structures/physical files
• No. of interfaces: different mechanisms used to exchange information with other systems

Step 2: Refine Parameters:

• The complexity of each category is graded in 3 broad
categories: simple, average, complex
• Based on these weights, the values of UFP are refined

Step 3: Refine UFP based on complexity of overall project:

• Albrecht identifies 14 parameters that can influence the development effort (upper figure)
• Each is assigned a value from 0 to 6 (low to high influence)
• Resulting numbers are summed = total degree of influence (DI)
• A technical complexity factor (TCF) for the project is computed and multiplied by UFP to get FP
• TCF = 0.65 + 0.01*DI FP = UFP*TCF 0 <= DI <= 84, 0.65 <= TCF <=1.49

Shortcomings of FP:
• Does not take algorithmic complexity of a function into account
2.1 System Analysis
(System Requirement, Stakeholders, Techniques for information gathering, Validating the requirements)

How is the SRS validated?

• After SRS is documented, it is reviewed internally by the project team to ensure that it accurately
captures all the user requirements and it is understandable, consistent, unambiguous and complete
• Then the customer reviews the SRS and agrees to it
• Serves as a contract between customer and development organization

Requirements Gathering:
• To collect requirements from the stakeholders
• A stakeholder is a source of requirements and is usually a person or group of persons who directly
or indirectly are concerned with the software
• Usually even before visiting the customer, requirement gathering starts by studying the existing
documents to collect all possible information about the system to be developed

Ways to Gather Requirements:

1. Studying Existing Documentation:
• Analyst studies all documents regarding the system to be developed before visiting the customer
• Customer provides Statement of Purpose (SoP)
• Documents: basic purpose, stakeholders, features of a similar software, etc
2. Interview:
• Each category of user requires a different set of features
• Use Delphi technique: analyst documents requirements and circulates for comments
• Process continues till all categories of users agree to the set of requirements
3. Task Analysis:
• A service supported by a software is also called a task
• For each task, analyst tries to formulate different steps necessary to realize the task
• Task analysis helps the analyst understand the nitty-gritty of various user tasks and represent each
task as a hierarchy of subtasks
4. Scenario Analysis:
• Different scenarios of a task may take place when task is invoked under different situations
• For each identified scenario, system response, conditions…are determined with user consultation
5. Form Analysis:
• Important and effective activity done by analyst when project involves automating an existing
manual system
• Manual system requires several forms to be filled by stakeholders & several notifications are sent
• The forms and notifications are analyzed to determine data input and output of the system

Requirements Analysis:
• What is the problem?
• Why is it important to solve the problem?
• What exactly are the data input and output to and by the system?
• What are the likely complexities that might arise while solving the problem?
• If there are external software or hardware with which the developed software has to interact, then
what should be the data interchange formats with the external systems?
• Problems to solve:
o Anomaly: several interpretations of a requirement are possible, ambiguity
o Inconsistency: one requirement contradicts the other
o Incompleteness: some requirements have been overlooked
Software Requirements Specification (SRS):
Stakeholders:
• Senior managers
• Project (technical) managers
• Practitioners
• Customers
• End users

Users of SRS:
• Users, customers and marketing personnel
• Software developers
• Test engineers
• User documentation writers
• Project managers
• Maintenance engineers

Why SRS?
• Forms an agreement between customers and developers
• Reduces future reworks
• Provides a basis for estimating costs and schedules
• Provides a baseline for validation and verification
• Facilitates future extensions

Characteristics of a good SRS:

• Concise
• Implementation independent
• Traceable
• Modifiable
• Identification of response to undesired events
• Verifiable

Attributes of bad SRS:

• Over specification
• Forward references
• Wishful thinking
• Noise

Functional Requirements:
• Captures functionalities required by the users from the system
• Software offers a set of functions {fi} such that each f : I -> O
• Meaning it transforms an element ii in input domain I to value oi in output O
• Must clearly describe each functionality that the system would support

Non-Functional Requirements:
• Out of the various non-functional requirements, the external interfaces and the design and
implementation constraints should be documented in two different section
• The remaining non-functional requirements should be documented later in a section and these
should include the performance and security requirements
 o Design & Implementation Constraints: describe any items or issues that will limit the
options available to the developers
o External Interfaces Required: hardware, software and communication interfaces, user
interfaces, report formats, etc
o Other Non-Functional Requirements: non-functional requirements that are neither design
constraints nor external interface requirements. Like reliability issues, accuracy of results,
security issues, performance requirements

Goals of Implementation:
• Not checked by the customer for conformance at the time of acceptance testing
• Issues such as easier revisions to the system functionalities, easier support for new devices, etc

Note: Refer SRS sample from PPT folder

Representing Complex Logic:

• High-level function – different steps –
decision making

Decision Tree:
• Edges of the decision tree represent conditions
• Leaf nodes represent actions to be performed
• Gives graphic view of logic involved in decision making and
corresponding actions taken

Decision Table:
• Shows the decision-making logic and the corresponding actions
taken in a tabular or a matrix form
• Upper rows specify the variables or conditions to be evaluated
• Lower rows specify the actions to be taken when an evaluation test
is satisfied
• A column in the table is called a rule
• A rule implies that if a certain condition combination is true, then the corresponding action is
executed

Decision Tree vs. Decision Tree:

1. Readability:
• Trees are easier to read
• Table causes analyst to consider every possible combination of conditions
2. Explicit representation of the order of decision making:
• The order of decision making is abstracted out in tables
• Tree is more useful in multilevel decision making
• Table can only represent single decision
3. Representing complex decision logic:
• Trees become more complex to understand when no. of conditions increases
• Table representation preferred when large no. of decisions are involved
2.2 System Analysis
(Feasibility Analysis, Tests for feasibility, Cost Benefit Analysis, Feasibility report. The system proposal)

2.3 System Analysis

(Data flow diagram and UML analysis diagrams)

Refer PPT for both

3.1 Software Design
(Software Design Specification- Abstraction, Modeling- Effective modular design, Cohesion and Coupling, Example of
code for cohesion and coupling)

Outcome of the Design Process:

• Different modules required
• Control relationships among modules
• Interfaces among different modules
• Data structures of the individual modules
• Algorithms required to implement the individual modules

Classification of Design Activities:

• Preliminary / High-Level Design:
o A problem is decomposed into a set of modules
o The control relationships and interfaces among modules are identified
o The modules are cohesive and have low coupling
o Outcome is a program structure or software architecture
• Detailed Design:
o Done after high-level design is complete
o Each module is examined carefully to design its data structures and algorithms
o Outcome is documented in form of a module specification (MSPEC) document
• After both activities, programmer can easily grasp them for initiating coding

Analysis vs. Design:

• Goal of analysis technique is to elaborate the customer requirements through careful thinking and
at the same time consciously avoiding making any decisions regarding the exact way the system is
to be implemented
• In case of function-oriented approach:
o Analysis model us documented using DFD
o Design model is documented using structure chart
• In case of object-oriented approach:
o Both are documented using UML

Characteristics of a good Software Design:

• Correctness
• Understandability
• Efficiency
• Maintainability

Understandability of a Design:
• It should assign consistent and meaningful names to various design components
• It should make use of principles of decomposition and abstraction to simplify the design
• A design solution should be modular and layered to be understandable

Modularity:
• Modular design: problem decomposed into a set of modules having limited interaction with each
other (dive and conquer principle)
• Basic characteristic of any good design – each module can be understood separately
• A design solution is highly modular if different modules have high cohesion and inter-module
coupling is low
Layered Design:
• Layered Design: when the call relations among different modules are represented graphically, it
would result in a tree-like diagram with clear layering
• Modules are arranged in a hierarchy of layers
• A module can only invoke functions of the module in the layer immediately below it
• Higher layer modules invoke the lower layer modules to get certain tasks done
• Implements complete abstraction: lower layer cant invoke higher or same level layer
• Simple debugging: lower layers may be possible sources of errors detected

Cohesion and Coupling:

• Cohesion is a measure of the functional strength of a module, whereas the coupling between two
modules is a measure of the degree of interaction (or interdependence) between the modules
• Two modules are said to be highly coupled if either of the following happens:
o If the function calls between two modules involve passing large chunks of shared data
o If the interactions occur through some shared data
• If two modules do not interact each other at all or interact by passing no or only a few primitive
data items, they are said to have low coupling

Functional Independence:
• A module that is highly cohesive and also has low coupling with other modules is said to be
functionally independent of the other modules
• Advantages:
o Error isolation:
§ Functional independence reduces the chances of the error propagating to other
modules
§ Makes it very easy to locate the error
o Scope of use:
§ Reuse of a module for the development of other applications becomes easier
o Understandability:
§ When modules are functionally independent, complexity of the design is greatly
reduced

Classification of Cohesiveness:
• Cohesiveness is the degree to which the different functions of the module co-operate to work
towards a single objective
• Different modules can possess different degrees of freedom
• A module is said to possess that particular cohesion if
Coincidental Logical Temporal Procedural Communicational Sequential Functional
it performs all a module the set of all functions of the different
a set of elements contains functions of the the module refer different functions
tasks that of the functions module are to or update the functions of of the
relate to module that are executed one same data the module module
each other perform related by after the other, structure execute in a co-
very loosely, similar the fact though these sequence, operate
if at all operations, that these functions may and the to
such as functions work towards output from complete
error are entirely 1 function is a single
handling, executed different input to the task
data input, in the purposes and next in the
output, etc same operate on very sequence
time span different data
 • If you need a compound sequence to describe the functionality of the module, then it has
sequential or communicational cohesion
• If you need words such as “first”, “next”, “after”, “then”, etc then it possesses sequential or
temporal cohesion
• If it needs words such as “initialize”, “setup”, “shut down”, etc to define its functionality, then it has
temporal cohesion

Classification of Coupling:
• The coupling between two modules indicated the degree of interdependence between them
• If two modules interchange a large amount of data, they are highly interdependent or coupled
• The degree of coupling between two modules depends on their interface complexity
• Two modules are said to be couples if
Data Stamp Control Common Content
They communicate They communicate Data from one They share some They share code,
using an using a composite module is used to global data items i.e., a jump from
elementary data data item such as a direct the order of one module into
item that is passed record in PASCAL instruction the code of
as a parameter or a structure in C execution in another module
between the two another can occur

Layered Arrangement of Modules:

• Control hierarchy of a design is determined by the order in which different modules call each other
• Refer Layered Design (pg.18)
• Top most module is the manager that only invokes services of lower level module to discharge its
responsibility
• Errors are isolated since error in one module can only affect the higher layer modules
• Concepts and terminologies:
o Superordinate and subordinate modules:
§ A module controls another module – superordinate & subordinate
o Visibility:
§ A module B is said to be visible to another module A, if A directly calls B
§ Thus, only immediately lower layer modules are visible to a module
o Control abstraction:
§ A module can only invoke functions of the module in layer immediately below it
§ Higher layers are abstracted to the modules at lower layers
o Depth and width:
§ Provide an indication of the no. of layers and overall span of control respectively
o Fan-out:
§ Measure of the no. of modules that are directly controlled by a given module
§ Higher fan out means module lacks cohesion – bad design
o Fan-in:
§ No. of modules that directly invoke a given module
 § High fan in means code reuse – good design

Approaches to Software Design:

• Function-oriented design
• Object-oriented design

Function-Oriented Design:
• Salient features:
o Top-down decomposition:
§ System viewed as a black box providing certain services to the users of the system
§ Starting at a high-level view of the system, each high-level function is successively
refined into more detailed functions
o Centralized system state:
§ The values of certain data items that determine the response of the system to a user
action or external event
§ The system state is centralized and shared among different functions

Object-Oriented Design:
• Each object is associated with a set of functions called methods
• Each object contains its own data and is responsible for managing it
• Use of decomposition and abstraction principles
o Data abstraction:
§ Data abstraction principle implies that how data is exactly stored is abstracted away
§ The entities external to the object can access the data internal to an object only by
calling certain well-defined methods supported by the object
o Data structure:
§ It is constructed from a collection of primitive data items
o Data type:
§ A type is a programming language terminology that refers to anything that can be
instantiated
§ ADT are user defined types
• Advantages of using abstract data type (ADT):
o The data of objects are encapsulated within the methods (data hiding)
o The encapsulation principle requires that data can be accessed and manipulated only
through the methods supported by the object and not directly
o An ADT-based design displays high cohesion and low coupling
o Abstraction makes the design solution easily understandable and helps to manage
complexity

Object-Oriented vs. Function Oriented Design Approach:

• In OOD, state information exists in the form of data distributed among several objects of the
system. In contrast, in a procedural design, the state information is available in a centralized shared
data store.
• Function-oriented techniques group functions together if, as a group, they constitute a higher-level
function. On the other hand, object-oriented techniques group functions together on the basis of
the data they operate on.
• Data is private in OOD
• The basic unit of designing an object-oriented program is objects, whereas it is functions and
modules in procedural designing.
3.2 Software Design
(User Interface Design- Human Factors, Interface standards- User Interface Design Process)

3.2 Software Design

(Application Architecture for Information System, Deployment using UML diagrams, Component and deployment
diagram for various architectures)

3.4 Software Design

(Design Patterns – Gang of four patterns)

Refer PPT for all

4.1 SQA
(Software estimation – Empirical estimation models – Cost/Effort estimation Planning – Work breakdown Structure,
Gantt Chart, Evaluate schedule and cost variance)

Project Estimation Techniques:

Empirical Estimation Techniques:
• Based on making an educated guess of the project parameters
• Based on common sense and subjective decisions
• 2 techniques:

1. Expert Judgement:
• An expert makes an educated guess about the project size after analyzing the problem thoroughly
• Expert estimated the cost of different components that make up the system and then combines
them to get the overall estimate
• Shortcomings:
o Human errors
o Individual bias
o Some factors overlooked
o Expert may not have relevant experience and knowledge of all aspects of project
o Overly optimistic estimates
• When done by a group of factors, errors due to above factors is minimized
• But, the decision made by a group may be dominated by overly assertive/senior members

2. Delphi Cost Estimation:

• Overcomes some shortcomings of expert judgement approach
• Carried out by a team comprising a group of experts and a coordinator
• Coordinator provides each expert with a copy of the SRS and a form for recording his estimate
• Estimators mention any unusual characteristic of the product that influenced their estimate
• The prepared summary information is distributed to the estimators based on which they re-
estimate
• This process is iterated for several rounds
• No discussions among estimators is allowed so that no influence
• The coordinator compiles the results at the end and prepares the final estimate
• Consumes more time and effort but estimate cannot be influenced by an overly assertive member

Heuristic Techniques:
• Heuristic estimation models are derived using regression analysis on data collected from past
software projects
• The overall structure of such models take the form E = A + B * (er)C
Where A, B, C are empirically derived constants. E is the effort in person-month and er is the
estimation variable (either LOC or FP)
• In addition to the general form, they have some project adjustment components that enable E to
be adjusted by other project characteristics like problem complexity, staff experience, development
environment, etc
• Based on the study different types of project, a rule of thumbs in the form of mathematical
expression
• The heuristic estimation models are also alternatively termed as algorithmic cost models
COCOMO:
• Stage 1: An initial estimate is arrived at (basic COCOMO)
• Stage 2 & 3: The initial estimate is refined to arrive at a more accurate estimate (intermediate and
complete COCOMO)

The Basic COCOMO Model:

• Boehm classified every project into – organic, semidetached and embedded based on development
complexity
• To classify, consider characteristics of the product, development team and development
environment
• Brooks development classes correspond to application, utility and system software
o Data process programs are application programs
o Compilers, linkers, etc are utility programs
o Operating systems and real-time system programs, etc are system programs
o Relative levels of product development complexity are 1:3:9
• Boehms:
o Organic:
§ Project deals with developing a well-understood application program
§ Size of development team is reasonably small
§ Team members are experienced in developing similar types of projects
o Semidetached:
§ Development team consists of a mixture of experienced and inexperienced staff
§ Team members may have limited experience on related systems but may be
unfamiliar with some aspects of the system being developed
o Embedded:
§ The software being developed is strongly coupled to hardware, or if stringent
regulations on the operational procedures exist
§ Team members may have limited experience on related systems but may be
unfamiliar with some aspects of the system being developed
• We predict effort (person-month) and development time from size estimation in kilo lines of source
code (KLSC)
• Effort = a1 * (KLOC)a2 PM Tdev (dev. time) = b1 * (Effort)b2 months
a1 a2 b1 b2
Organic 2.4 1.05 2.5 0.38
Semidetached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32

Person-Month (PM):
• One person-month is the effort an individual can typically put in a month
Estimation with Use Cases:
• Estimation with use cases is problematic for the following reasons:
o Use cases are described using many different formats and styles—there is no standard form.
o Use cases represent an external view (the user’s view) of the software and can therefore be
written at many different levels of abstraction.
o Use cases do not address the complexity of the functions and features that are described.
o Use cases can describe complex behavior (e.g., interactions) that involve many functions
and features.
• Use cases can be used for estimation only if they are considered within the context of the structural
hierarchy that they are used to describe
• Any level of structural hierarchy can be described by 10 use cases each having max 30 distinct
scenarios
4.2 SQA
(Risk Management Risk Identification, Risk Assessment, Risk Projection, RMMM)

Risk Management:
• A risk is an anticipated unfavorable event or circumstance that can occur while a project is
underway
• If a risk becomes real the anticipated problem becomes a reality and is no more a risk
• It can affect project and hamper the successful timely completion of the project
• Risk management aims at reducing the chances of a risk becoming real as well as reducing the
impact of risks that become real
• It consists of 3 essential activities: risk identification, risk assessment and risk mitigation

Risk Identification:
• Project Risks:
o Concern various forms of budgetary, schedule, personnel, resource and customer-related
problems
o Difficult to monitor and control is project is tangible
o The invisibility of the product being developed is an important reason why many software
projects suffer from the risk of schedule slippage
• Technical Risks:
o Concern potential design, implementation, interfacing, testing and maintenance problems
o Also include ambiguous specification, incomplete specification, changing specification,
technical uncertainty and technical obsolescence
o Mostly occur due to development team’s insufficient knowledge about the product
• Business Risks:
o Includes risk of building an excellent product that no one wants, losing budgetary
commitments, etc
• To successfully foresee and identify risks, make a complete disaster list containing all the bad
events that have happened to software projects of the company over the years including events
that can be laid at the customer’s door

Risk Assessment:
• Objective: to rank risks in terms of their damage causing potential
• Each risk must be rated in 2 ways:
o Likelihood of the risk becoming real (r = probability of risk becoming real)
o Consequence of the problems associated with that risk (s = severity of damage cause if real)
• Priority of risk p = r * s

Risk Mitigation:
• Find ways to either decrease the probability of the risk event happening or the impact of the event
happening
• Different types of risks require different containment procedures
• 3 strategies:
o Avoid the risk:
§ Risks often arise due to project constraints and can be avoided by suitably modifying
the constraints
§ Categories of constraints:
• Process-related risk: arise due to aggressive work schedule, budget, resource
utilization
• Product-related risk: arise due to commitment to challenging product
features, quality, reliability
 • Technology-related risk: arise due to commitment to use certain technology
o Transfer the risk:
§ This strategy involves the risky components developed by a third party, buying
insurance cover, etc
o Risk reduction:
§ Involves planning ways to contain the damage due to a risk
§ For technical risks: build a prototype
• Project manager must consider the cost of handling and reduction of the risk
• Risk leverage = (risk exposure before reduction – risk exposure after reduction)/(cost of reduction)

Example of handling Schedule Slippage Risk:

• Arises primarily due to intangible nature of software
• Step 1 is to increase the visibility of the software product
• Visibility of a software product can be increased by producing relevant documents during the
development process and getting these documents reviewed by an appropriate team
• Milestones should be placed at regular intervals to provide a manager with regular indication of
progress
• Milestone not needed for every activity, approx. rule of thumb of every 10 to 15 days
4.3 SQA
(Software Configuration Management, SCM process, version and change control)

Software Configuration Management:

• The output of the software process is information of 3 categories:
o Computer programs
o Work products that describe the computer programs
o Data or content
• The items that comprise all information produced as part of the software process are collectively
called a software configuration.
• Software configuration items (SCIs): a named element of information that can be as small as a
single UML diagram or as large as the complete design document

SCM Scenario:
• Project manager in charge of a software group
• Configuration manager in charge of the CM process and policies
• Software engineers responsible for developing and maintaining the software product
• Customer who uses the product
• Assume that product is small, 15000 lines of code developed by a team of 6 people
• Project manager goal: to ensure that the product is developed within certain time frame
o Monitors the progress of development and recognizes and reacts to problems by generating
and analyzing reports about status of software system and performing reviews on them
• Configuration manager goal: to ensure the procedures & policies for creating, changing and testing
code are followed and to make project information accessible
o Introduces mechanisms for making official requests for approving changes, evaluating them
and authorizing changes for maintaining control over code
• Software engineers’ goal: to work effectively without interfering with each other in creation/testing
of code
o Communicate and coordinate by notifying each other about tasks required and completed
• Customer follows formal procedures for requesting changes for indicating bugs in the product

Elements of a Configuration Management System:

• Component elements: a set of tools coupled within a file management system (e.g., a database)
that enables access to and management of each software configuration item
• Process elements: a collection of actions and tasks that define an effective approach to change
management (and related activities) for all constituencies involved in the management,
engineering, and use of computer software
• Construction elements: a set of tools that automate the construction of software by ensuring that
the proper set of validated components (i.e., the correct version) have been assembled
• Human elements: a set of tools and process features (encompassing other CM elements) used by
the software team to implement effective SCM

Baseline:
A baseline is a software configuration management concept
that helps you to control change without seriously impeding
justifiable change

SCIs:
• Organized to form configuration objects that may be
cataloged in the project database with a single name
 • A configuration object has a name, attributes, and is “connected” to other objects by relationships

SCM Process:
• The software configuration management process defines a
series of tasks that have four primary objectives:
o to identify all items that collectively define the software
configuration
o to manage changes to one or more of these items
o to facilitate the construction of different versions of an
application
o to ensure that software quality is maintained as the
configuration evolves over time

Identification of Objects in the Software Configuration:

• To control and manage software configuration items, each should be separately named and then
organized using an object-oriented approach
o Basic Object:
§ Unit of information that you create during analysis, design, code, or test
§ Example: a section of SRS, a part of design model, a suite of test cases, etc
o Aggregate Object:
§ A collection of basic objects and other aggregate objects
§ Example: ArchitecturalModel, DataModel, UMLClassDiagram
• Configuration object identification can also consider the relationships existing between objects
o Class diagram <part-of> requirements model;
o Requirements model <part-of> requirements specification;

Version Control:
• Combines procedures and tools to manage different versions of configuration objects that are
created during the software process
• 4 major capabilities:
o A project database that stores all relevant configuration objects
o A version management capability that stores all versions of a configuration object
o A make facility that enables you to collect all relevant configuration objects and construct a
specific version of the software
o Implement an issues tracking capability that enables the team to record and track the status
of all outstanding issues associated with configuration object
• Change set: a collection of all changes (to some baseline configuration) that are required to create a
specific version of the software

Change Control:
• A change request is submitted and evaluated to assess technical merit, potential side effects,
overall impact on other configuration objects and system functions, and the projected cost of the
change
• The results of the evaluation are presented as a change report, which is used by a change control
authority (CCA)—a person or group that makes a final decision on the status and priority of the
change
• An engineering change order (ECO) is generated for each approved change
• The ECO describes the change to be made, the constraints that must be respected, and the criteria
for review and audit
• For every change, version control mechanisms are applied
 • These version control mechanisms, integrated within the change control process, implement two
important elements of change management
o Access control: governs which software engineers have the authority to access and modify a
particular configuration object
o Synchronization control: helps to ensure that parallel changes, performed by two different
people, don’t overwrite one another

Configuration Audit:
• How can a software team ensure that the change has been properly implemented?
o Technical review:
§ focuses on the technical correctness of the configuration object that has been
modified
§ The reviewers assess the SCI to determine consistency with other SCIs, omissions, or
potential side effects
o Software configuration audit:
§ Complements the technical review by assessing a configuration object for
characteristics that are generally not considered during review
• Audit answers the following questions:
1. Has the change specified in the ECO been made? Have any additional modifications been
incorporated?
2. Has a technical review been conducted to assess technical correctness?
3. Has the software process been followed and have software engineering
standards been properly applied?
4. Has the change been “highlighted” in the SCI? Have the change date and change author been
specified? Do the attributes of the configuration object reflect the change?
5. Have SCM procedures for noting the change, recording it, and reporting it been followed?
6. Have all related SCIs been properly updated?

Status Reporting:
• Configuration status reporting (CSR) or status accounting: an SCM task that answers the following
questions
o What happened?
o Who did it?
o When did it happen?
o What else will be affected?
4.4 SQA
(Quality Metrics)

Refer Techmax pics

5.1 Software Testing

(Software Testing Basic concept and terminology, Verification & Validation, White Box Testing, Black Box Testing,
Integration, Validation and system testing)

4.4 Software Testing

(OO testing methods- class testing, interclass testing, testing architecture, behavioral testing)

Refer PPT