Software Process

1 10/20/23
Layered Technology

2 10/20/23
3 10/20/23
Layered Technology

• Software development is totally a layered technology.

• to develop software one will have to go from one layer to

another.

• Each layer demands the fulfillment of the previous layer.

4 10/20/23
 • Starts from Bottom
Quality
• Process is done to
develop sw.
• Each process contains
many methods
• Tools is automate or
semi automate.
• Tools support process
and methods

5 10/20/23
• 1. Quality—
• Software engineering must rest on an organizational commitment to quality.
• Continuous process improvement culture.
• mature approaches to software engineering.
• Acts as bed rock that gives quality focus

• 2. Process—
• The foundation for software engineering is the process layer.
• Defines a framework for a set of Key Process Areas (KPAs) that must be
established for effective delivery of software engineering technology.
• Management control of software projects
• Establishes the contest in which technical methods are applied..
• models, documents, data, reports, forms.

6 10/20/23
• work products (models, documents, data, reports, etc.) are
produced,
• milestones are established,
• quality is ensured,
• and change is properly managed.

7 10/20/23
• 3. Methods—

• Methods provide the technical how-to's for building software.

• Methods will include requirements analysis, design, program
construction, testing, and support
• .
• 4.Tools—

• Automated or semi-automated support for the process and the

methods.

• When tools are integrated so that information created by one

tool can be used by another
8 10/20/23
Process ?

9 10/20/23
10 10/20/23
11 10/20/23
12 10/20/23
13 10/20/23
The Software Process

14 10/20/23
15 10/20/23
five key activities

• The framework activities are applicable to all projects and all

application domains, and they are a template for every process
model.

• Software process
• Process framework
• Umbrella activities
• Framework activity #1
• Software Engineering action

16 10/20/23
• Each framework activity is populated by a set of S/W eng
actions –
• A collection of related tasks that produces a major S/W eng
work product (design is a S/W eng action).
• Each action is populated with individual work tasks that
accomplish some part of the work implied by the action.

17 10/20/23
Generic process framework
• Communication: involves heavy communication with the customer (and
other stakeholders) and encompasses requirements gathering.
• Planning: Describes the technical tasks to be conducted, the risks that are
likely, resources that will be required, the work products to be produced and
a work schedule.

• Modeling: encompasses the creation of models that allow the developer and
customer to better understand S/W req. and the design that will achieve
those req.

• Construction: combines code generation and the testing required

uncovering errors in the code.

• Deployment: deliver the product to the customer who evaluates the

delivered The following generic process framework is applicable to the vast
majority of S/W projects.
18 10/20/23
• The framework described in the generic view of S/W eng is complemented
by a number of umbrella activities.

• Umberlla activities

• S/W project tracking and control: allows the team to assess progress
against the project plan and take necessary action to maintain schedule.

• Risk Management: Assesses the risks that may affect the outcome of the
project or the quality.

• Software quality assurance: defines and conducts the activities required to

ensure software quality.

19 10/20/23
• Formal Technical Review: uncover and remove errors before they
propagate to the next action.

• Measurement: defines and collects process, project, and product measures

that assist the team in delivering S/W that meets customers’ needs.

• Software configuration management: Manages the effect of change

throughout the S/W process

• Reusability management: defines criteria for work product reuse.

• Work product preparation and production: encompasses the activities

required to create work products such as models, documents, etc.

20 10/20/23
• Task Sets : Collection of Software engineering work tasks,
project mile stones, workproducts, quality assurance points
• Task sets satisfy the project team

• Umbrella activities: Quality assurance, configuration

management, and measurement overlay the process model.
• Umbrella activities are independent of any one framework
activity & occur through out the process.

21 10/20/23
SEI: Software Engineering Institute
• Has a model on sw engg capabilities.
• State organizations has different levels of process maturity,
• It uses a assessment of 5 point grading scheme.
• The scheme defines key activities required at different levels of
process maturity.

• Level 1 ( Initial)
• Level 2 ( repeatable)
• Level 3 ( Defined )
• Level 4 ( managed )
• Level 5 ( Optimizing)

22 10/20/23
• Level 1 ( Initial) Sw process is Adhoc, chiotic
• Only few process are defined and requires individual effort.
• Level 2 ( repeatable): Proj management process is establishes to
track cost, schedule & functionality
• Aim : is to repeat earlier success.

• Level 3 ( Defined): The sw process for both management and

engineering activities is documented, standardized , integrated to a
organization wide sw process.
• Includes all aspects in level2

• Level 4 ( Managed ): Detailed measures of the software process

and product quality are collected.
•
23
Includes level3
10/20/23
• Level 5 ( optimizing): Continuous process improvement is
enabled by quantitative feedback from the process & from
testing innovative ideas and technologies.

24 10/20/23
Phases of a problem solving loop

25 10/20/23
26 10/20/23
Program vs. software product

• Programs are developed by individuals for their personal use.

• limited functionality but
• Program-
• the user interface may not be very important
• programmer’s individual style
• the programmer himself is the sole use

• On the other hand

• developers of that product and users of that product are totally different
• software products are extremely large.
• Documentation..very important

27 10/20/23
28 10/20/23
29 10/20/23
30 10/20/23
SOFTWARE PROCESS MODEL (SOFTWARE
LIFE CYCLE MODEL)
• A software life cycle model (also called process model) is a descriptive and
diagrammatic representation of the software life cycle.

• A life cycle model represents all the activities required to make a software
product.
• Maps the different activities performed on a software product from its
inception to retirement.
• systematic and disciplined manner.
• For team – When & what to do..?
• Example…
In a team, every one given freedom to do his wish on divided parts…
programming.
test documenting
Design phase …

31 10/20/23
• A software life cycle model defines entry and exit criteria for
every phase.

• Difficult for software project managers to monitor the progress

of the project.

• Considered to be a theoretical way of developing software.

32 10/20/23
33 10/20/23
Waterfall Model

34 10/20/23
Waterfall Model

• At first project managers or team leaders try to have a rough understanding.

• They study different input data & Output data.
• Pick the best solution
• solution is feasible financially and technically.

• Phase 1

• Requirements gathering and analysis, and

• Requirements specification

35 10/20/23
• Phase 2
• Design phase is to transform the requirements

• Specified in the SRS document into a structure that is suitable for

implementation in some programming language

• 2 types

• Traditional design approach-- first a structured analysis of the

requirements specification.
• This is followed by a structured design-- & the results of
structured analysis are transformed into the software design.

• Object-oriented design approach-- various objects that occur in the

problem domain and the solution domain are first identified
• Different relationships that exist among these objects are identified.
36 10/20/23
• Coding & Testing: Phase 3 & 4
• software design into source code.

• Each component of the design is implemented as a program module.

• The end-product of this phase is a set of program modules that have been
individually tested.
• Each module is unit tested to determine the correct working of all the
individual modules

• Activities undertaken during integration and system testing

• 1.Integration of different modules is undertaken.

• 2.Finally, when all the modules have been successfully integrated and tested,
system testing is carried out.
• 3.System testing confirms SRS.
37 10/20/23
Testing

38 10/20/23
System Testing
• α
• – testing: It is the system testing performed by the development
team, internal employees of the organization
• Alpha testing requires a lab environment or testing environment , Long execution cycle
• Alpha testing is to ensure the quality of the product before moving to Beta testing
• β
• – testing: It is the system testing performed by a friendly set of
customers, Clients or End Users, at a client location
• doesn't require any lab environment or testing environment & Most issues will be
implemented in future versions of the product
• Reliability, Security, Robustness are checked during Beta Testing
• Acceptance testing:
• It is the system testing performed by the customer himself after
the product delivery to determine whether to accept or reject the
delivered product.
39 10/20/23
• Maintenance– Phase 5
• Developing to maintenance effort is 40:60

• Mainly involves 3 activities.

• 1.Correcting errors that were not discovered during the product

development phase.

• 2. Improving the implementation of the system, and enhancing

the functionalities of the system according to the customer’s
requirements.

• 3. Porting the software to work into new environment.

40 10/20/23
Disadvantages

• Engineers are not allowed to commit errors.

• The source of the defects can be many: oversight, wrong

assumptions, use of inappropriate technology communication
gap among the project engineers, etc.

• Above defects only detected in later lifecycle.

41 10/20/23
Waterfall model

42 10/20/23
High lights

• Classic lifecycle model

• Oldest model
• Linear model
• Sequential model
• Manufacturing & construction

43 10/20/23
 Advantages of Waterfall Model
• The advantage of waterfall development is that it allows for
departmentalization and control.
• A schedule can be set with deadlines for each stage of development and a
product can proceed through the development process model phases one by
one.

• The waterfall model progresses through easily understandable and

explainable phases and thus it is easy to use.

• It is easy to manage due to the rigidity of the model – each phase has
specific deliverables and a review process.

• In this model, phases are processed and completed one at a time and they do
not overlap.
• Waterfall model works well for smaller projects where requirements are
very well understood.
44 10/20/23
Disadvantages of waterfall model
• It is difficult to estimate time and cost for each phase of the
development process.

• Once an application is in the testing stage, it is very difficult to

go back and change something that was not well-thought out in
the concept stage.

• Not a good model for complex and object-oriented projects.

• Not suitable for the projects where requirements are at a

moderate to high risk of changing.

45 10/20/23
46 10/20/23
47 10/20/23
48 10/20/23
Prototyping Model

49 10/20/23
50 10/20/23
51 10/20/23
Prototyping Model

52 10/20/23
53 10/20/23
Prototyping Model
• Mechanism for gaining better understanding of the customer’s needs:

• how the screens might look like ?

• how the user interface would behave ?
• how the system would produce outputs ?

• The client can get a model or sample of the product.

• Reasons

• Used when technical solutions are unclear to the development team

• Impossible to get the perfect product in the first attempt.

54 10/20/23
• A prototype of the actual product is preferred in situations such as:

• • user requirements are not complete -- software like bi

lling in a retail shop, accounting in a firm.

• • technical issues are not clear -- A Project involves writing a compiler and the
development team has never written a compiler.
• the team can consider a simple language, & check issues.

• After successfully building a small compiler (prototype), they would extend it to

one that supports a complete language.

•
55 10/20/23
56 10/20/23
Advantages of Prototype model
• Sometimes it helps to demonstrate the concept to prospective
investors to get funding for project.

• It reduces risk of failure, as potential risks can be identified early and

corrective steps can be taken.

• Iteration between development team and client provides a very good

and conductive environment during project.

• Since in this method a working model of the system is provided, the

users get a better understanding of the system being developed and
can suggest changes and modifications.

• User feedback is available at an early stage leading to better solution.

57 10/20/23
Disadvantages of Prototype model

• If too many changes are required in the sample or model

product, it can disturb the rhythm of the development team.

• This methodology may increase the complexity of the system as

scope of the system may expand beyond original plans.

• Prototyping is usually done at the cost of the developer. So it

should be done using minimal resources.

• Sometimes the start-up cost of building the development team,

focused on making prototype, may be high.

58 10/20/23
Spiral Model

59 10/20/23
60 10/20/23
61 10/20/23
Spiral Model

62 10/20/23
• spiral with many loops.
• number of loops in the spiral is not fixed.

• Each loop of the spiral represents a phase of the software process.

• For example,
• the innermost loop might be concerned with feasibility study.
The next loop with requirements specification, the next one with
design, and so on

• Each phase in this model is split into four sectors (or quadrants)

63 10/20/23
• First quadrant (Objective Setting)

• •During the first quadrant, it is needed to identify the objectives of the phase.
• •Examine the risks associated with these objectives

• Second Quadrant (Risk Assessment and Reduction)

• A detailed analysis is carried out for each identified project risk.

• Steps are taken to reduce the risks.

• For example, if there is a risk that the requirements are inappropriate, a

prototype system may be developed.

64 10/20/23
• Third Quadrant (Development and Validation)

• Develop and validate the next level of the product after

resolving the identified risks.

• Fourth Quadrant (Review and Planning)

• Review the results achieved so far with the customer and plan
the next iteration around the spiral.

• Progressively more complete version of the software gets built

with each iteration around the spiral.

65 10/20/23
Situations to use spiral or Applications
• When costs there is a budget constraint and risk evaluation is
important.

• For medium to high-risk projects.

• Long-term project commitment because of potential changes to

economic priorities as the requirements change with time.

• Customer is not sure of their requirements which is usually the case.

• Requirements are complex and need evaluation to get clarity.

• New product line which should be released in phases to get enough

customer feedback.
66 10/20/23
Situations to use spiral
• Risk handling is inherently built.

• Development of technically challenging software products

• Not used in ordinary projects.

• Significant changes are expected in the product during the

development cycle.

67 10/20/23
Advantages of Spiral Model

• Changing requirements can be accommodated.

• Allows for extensive use of prototypes Requirements can be

captured more accurately.

• Users see the system early.

• Development can be divided into smaller parts and more risky

parts can be developed earlier which helps better risk
management

68 10/20/23
Disadvantages of Spiral Model
• Management is more complex.

• End of project may not be known early.

• Not suitable for small or low risk projects and could be

expensive for small projects.

• Process is complex Spiral may go indefinitely.

• Large number of intermediate stages requires excessive

documentation.

69 10/20/23
Incremental Models
1. Iterative Incremental Model & 2 . Rapid Application
Development Model

70 10/20/23
71 10/20/23
Incremental models
• Designed, implemented and tested incrementally

• Little more added each time

• First increment is the core product.( used by customer)

• Then a plan is made for next increment.

• Actually modification of core product happens.

• Early increments are stripped down versions of final product.

• Guarantees the delivery of operational product with every increment

72 10/20/23
• At any time, the plan is made just for the next increment and
not for any kind of long term plans.

• Therefore, it is easier to modify the version as per the need of

the customer.

• Successive version model.

• Each incremental version is usually developed using an iterative

waterfall model of development.

73 10/20/23
74 10/20/23
75 10/20/23
Advantages of Incremental Model
• Generates working software quickly and early during the
software life cycle.

• More flexible – less costly to change scope and requirements.

• Easier to test and debug during a smaller iteration.

• Easier to manage risk because risky pieces are identified and

handled during its iteration.

• Each iteration is an easily managed milestone.

76 10/20/23
Advantages

• If core product is well received additional staff can be hired.

• Useful when staffing is unavailable for complete

implementation for deadline of project.

• Helps to manage risks.

• Risks with hardware components….

77 10/20/23
Disadvantages
• Each phase of an iteration is rigid and do not overlap each
other.

• Problems may arise pertaining to system architecture because

not all requirements are gathered up front for the entire software
life cycle.

78 10/20/23
Where to use Incremental Model
• Mostly such model is used in web applications and product
based companies.

• Where requirements are clear and can implement by phase

wise.

79 10/20/23
Rapid Application Development Model

80 10/20/23
Rapid application development model
• Is incremental software process model.
• Focus on short development cycle.( 60 to 90 days) very short devp. cycle
• Can be mentioned as the high speed adaptation of waterfall model.
• Each team do their own fraction of work
• Requires heavy resourses and people should be heavily committed.
• 1&2. Communication & planning is needed
• 3. modeling contains three major phases.
• business modeling
• data modeling
• process modeling.
• 4. Construction
• component reuse
• automatic code generation
• testing.
• 5. Deployment.
• integration
• delivery & feedback
81 10/20/23
• Business process model:

• Defines the ways in which operations are carried out to

accomplish the intended objectives of an organization.

• Data Model:
• used in software engineering to produce a type of conceptual
data model (or semantic data model) of a system

82 10/20/23
83 10/20/23
Risk in RAD

• RAD requires sufficient human resources & teams.

• If developers , customers are not committed RAD will fail.

• If not properly modularized building components will not be easy.

• If high performance is issue, performance is achieved through the tuning

of interfaces to system components
• But will not work

• RAD is not suitable when technical risks are high.

•

84 10/20/23
Concurrent Development Model

85 10/20/23
86 10/20/23
87 10/20/23
88 10/20/23
89 10/20/23
90 10/20/23
91 10/20/23
92 10/20/23
93 10/20/23
Computer-aided software engineering (CASE)

• The domain of software tools used to design and implement

applications.

• Similar to CAD in designing hardware products.

• CASE tools available to simplify various stages of Software

Development Life Cycle such as Analysis tools, Design tools,
Project management tools, Database Management tools,
Documentation tools

94 10/20/23
Components of CASE Tools

95 10/20/23
• Central Repository - CASE tools require a central repository,
which can serve as a source of common, integrated and
consistent information/ Database.

• Upper Case Tools - Upper CASE tools are used in planning,

analysis and design stages of SDLC.

• Lower Case Tools - Lower CASE tools are used in

implementation, testing and maintenance.

• Integrated Case Tools - Integrated CASE tools are helpful in

all the stages of SDLC, from Requirement gathering to Testing
and documentation.

96 10/20/23
Case Tools Types
• Diagram tools : These tools are used to represent system
components, data and control flow among various software
components and system structure in a graphical form.
• Example: Flowchart maker
• Process Modeling Tools:
• Creates software process model.
• choose a process model or modify it as per the requirement of
software product.
• Example:Eclipse process framework
• Project Management Tools:
• project planning, cost and effort estimation, project scheduling
and resource planning.
• Example: Trac Project

97 10/20/23
• Documentation Tools:
• Documentation in a software project starts prior to the software
process.

• Documentation tools generate documents for technical users

and end users.
• Example-- Doxygen.

• Analysis Tools:
• gather requirements, automatically check for any inconsistency,
inaccuracy in the diagrams, data redundancies or erroneous
omissions.
• Example-- Accept 360.
98 10/20/23
• Design Tools:
• help software designers to design the block structure of the
software.
• further be broken down in smaller modules using refinement
techniques.
• Example :Animated Software Design

• Configuration Management Tools:

• Version and revision management
• Change control management
• Example : git

99 10/20/23
• Programming Tools :
• programming environments like IDE (Integrated Development
Environment), in-built modules library and simulation tools.
• include features for simulation and testing.
• Example :Cscope to search code in C, eclipse

• Prototyping Tools :
• These tools help us to build rapid prototypes based on existing
information.
• Example:Mockup Builder.

• Web Development Tools:

• These tools assist in designing web pages with all allied elements like
forms, text, script, graphic and so on.
•100 Example:
10/20/23 Fontello
• Quality Assurance Tools:
• ensure conformance of quality as per organization standards.
• Example: SoapTest, AppsWatch

• Maintenance Tools:

• Software maintenance includes modifications in the software product

• Example: Bugzilla

101 10/20/23
Historical Aspects

• Study group in 1967 coined the term software engineering.

• similar to other engineering tasks.

• Used to solve crisis.

• quality was low..
• deadlines not met…
•

102 10/20/23
• Another study of 2,80000 projects in 2000 only 28% completed sucessfully.

• 9236 projects in 2004 only 29 % successfully done.

• 2006 only 35 %..

• Cancelled is 19%, completed late, over budget , missing features.

103 10/20/23
Economic Aspects

• Budget or cost is important.

• CT old
• CT New..

• Nine tenth of the time…

• So nine tenth is the cost
• Coding is 10 percent faster
• Reason 1
• To learn new methods of coding training is needed.
• To get that money spent need to complete atleast 3 projects..
• CT new will take far longer time to completion than if continued in CT old.

104 10/20/23
• Reason 2
• Engineers agree on speed, quality…of CT New.
• But
• CT new..Code difficult to maintain.
• Then cost will be higher over life of the product.
• if the developer don’t want to maintain the product then he will recommend CT
New.

105 10/20/23
• Situation 2:

• Client knows CT new will cost 10 percent less.

• Client insist that CT old is to be used expecting the lifetime cost is lower.

• Both from client side & programmer side the aim is to reduce costs.

• Long term effects of using particular technique generally ignored in interest of short
term gain & the decision is made by client.

106 10/20/23
Maintenance Aspects

• Described with software Lifecycle- 5 Phases..

• Until 70 most companies used Waterfall model
• But organizations lack this six phases../ not correspond to …/ precise name varies
from one organization to another.
• 1. Requirements phase- concept explored, refined, clients requirements elicited.
• 2. Analysis( Specification )- clients requirements is analyzed & presented in
specification document.
• End of this phase plan is drawn up.
• 3.Design phase- 2 procedures are done here.
• A) architectural design: product as a whole is broken into components/ modules.
• B) Then each module is designed known as detailed design.
• 4. Implementation phase- coding & testing( unit testing & integration testing is
done), acceptance testing.

107 10/20/23
• 5.postdelivary maintenance- changes done unce sw delivered ( software repair).

• Means removal of residual faults, while leaving the specifications unchanged.

• Perfective maintenance- changes that the client think will improve the effectiveness
of the product
• Eg: additional functionality, decreased response time..

• Adaptive maintenance- Changes made in response to changes in environment in

which the product operates..( new hardware, OS..)

• 6. Retirement:

108 10/20/23
Specification Document

• The documentation typically describes what is needed by the

system user as well as requested properties of inputs and
outputs (e.g. of the software system).

109 10/20/23
• In 1970’s there are two distinct activities..
• 1. software development..
• 2. maintenance.

• But today it is unrealistic

• Developers has to provide maintenance before the product has installed.

• “ Is the process that occurs when software undergoes modifications to code

and associated documentation due to problem or need for improvement ,
adaptation.”

110 10/20/23
• ISO- International organization for standardization.
• 147 countries.
• central secretariat in Geneva.

• IEC– International Electrotechnical commission.

• Non govt. organisation.
• Prepares & publishes international standards for electrical electronic & related technologies.

• EIA– Electronic Industries Alliance

• Trade organization
• contains alliance & trade associations.
• For electronics manufactures in United states.
•

111 10/20/23
• IEEE–
• Institute of electrical & electronic engineers.
• non profit organization.
• For development of technology related to electricity.
• 395000 members across 150 countries.
• Highly sited publications, conferences, technology standards, professional &
educational activities.

112 10/20/23
Importance of post delivery maintainance

• Real world is changing.

• Software has to be maintained constantly.

• How much time ( money ) is devoted to post delivery maintenance.

• 40 years before – 2/3 of software costs..

• New data 70% to 80 %.

• But average cost percentage of classical development remains same.
• Cost of correcting fault increases steeply through out the phases.

113 10/20/23
• Fault in requirements may also appear in specifications, design, and code.

• Out of faults detected between 60 % and 70 % of all faults detected in large

projects – requirements, analysis, design faults.

• ie – we want to improve requirements, analysis & design techniques.

114 10/20/23
115 10/20/23
116 10/20/23
Modern Views of maintenance…

• Unusual for construction of a product to take a year.

• During this time the clients requirements may change.

• Developing a product from scratch VS reuse of exixting

software products.

117 10/20/23
Team development aspects

• Software is a team effort.

• Team development leads to interface problems.
• ( code)
• Communication problem among team members.
• Unless team is well organized time will be wasted as team
meetings.
• Includes economic aspects, legal aspects, copyright law.

118 10/20/23
Planning phase

• Not possible to develop software without planning.

• Happens in levels
• 1.preliminary planning happens managing requirement & analysis phase.

• 2.once precise idea is formed..Software project management plan is drawn.

• ( budget, staffing, requirements, detailed schedule)

• When specification document is signed by client ..it is end of
analysis phase.
• Till that time planning is preliminary.

• 3. Till end of project the management needs to monitor the SPMP, & can watch for any
deviation.

119 10/20/23
Testing

• Occurs in end of each phase—known as verification.

• When client do that job– validation.

• When testing is considered as entirely separate phase , its dangerous.

• It should be done continuous.

• In Industry there is a separate group..

• Ensures—clients needs, product built correctly,

• Software Quality Assurance Team ( SQA)

120 10/20/23
Planning Phase
• Three types of planning.
• 1. At the beginning of project preliminary planning takes place for managing
the requirements & analysis phase.

• 2. Then software project management paln ( SPMP ) is drawn

• SPMP- Includes budget, staffing requirements & detailed schedule.

• 3.Through the project management monitors the SPMP.

121 10/20/23
Documentation

• Done at all times.

• Impossible to perform testing without seeing the documents that show how
the product is supposed to behave.

• Impossible to perform maintenance without documentation that describes

precisely what the product does.

122 10/20/23