It601 Se Material Till Class Test PDF

SE Material Till Class Test
Prof. Daiwat Vyas

Syllabus
• Software process and lifecycle: Software Product, Software
Processes, Study of different process models, Project Management
Concepts, Planning and Scheduling, Team organization and people
management.
• Software requirement engineering: Software requirements,
extraction and specification, Feasibility Studies, Requirements
Modeling, object oriented analysis.
• Design Concepts: Object oriented design, Architectural design.
Component level Design, User Interface Design, Distributed Systems
Architecture, Real Time Software Design, User Interface Design,
Pattern Based Design.
Syllabus
• Risk Management: Metrics and Measurement, Estimation for software
projects, software configuration management, Maintenance and
Reengineering
• Software Testing: Unit testing, integration testing, black box and white
box testing, regression testing, performance testing, object oriented
testing.
• Verification and validation of Software: Software Inspections and
Audit, Automated Analysis, Critical systems validation Software Quality
Assurance, Quality Standards, Quality Planning and Control, Various
Quality models.
• Overview of recent trends in Software Engineering, Security Engineering,
Agile Methods, Service Oriented Software Engineering, Aspect Oriented
Software Development.
Syllabus
Reference Books:
• Ian Sommerville, Software Engineering, Addison – Wesley
• Roger Pressman, Software Engineering A Practitioners Approach,
McGraw Hill Publication
• Rajib Mall, Fundamentals of Software Engineering, Prentice Hall of
India
• Ivar Jacobson, Object Oriented Software Engineering A use case
Approach, Pearson
Course Learning Outcomes (CLO):
CLO1
understand various phases of software development lifecycle
CLO2
analyze the requirements systematically and develop the model using standard tools and
methodologies
CLO3
apply key aspects of software engineering processes for the development of a complex
software system
CLO4
develop a quality software project through effective team-building, planning, scheduling

and risk assessment
CLO5
keep abreast of current trends in the area of software engineering
Course Evaluation Scheme
COMPONENTS WEIGHTAGE
Course Details Continuous Evaluation (CE) LPW
Class test Sessional Special Lab Term
Course Exam Assignment Work End
Subject Subjec No. of
Coordinator Exam
Code t Practi-
Name cals
WT Type of WT WT WT
Weightage (WT) Assignme
nt
Term
0.3 0.4 0.3 0.75 0.25
Prof. Daiwat Paper
IT601 SE (*) 10
Vyas 0.75+0.25=1.0 
0.3+0.4+0.3 =1.0  WT: 0.4
WT: 0.2
* SE: Software Engineering
Final Break-up for Course Evaluation: 0.4 of CE + 0.4 of SEE + 0.2 of total of LPW component = 1
Lesson Planning
• IT601 Lesson Planning Even Sem 2016-17
List of Practicals
• IT601 List of Practicals Even Sem 2016-17
Introduction
• What is Engineering?
• Engineering is all about developing products, using well-defined,

scientific principles and methods.
• Engineering is the application of well-understood scientific

methods to the construction, operation, modification and
maintenance of useful devices, products and systems etc.
Introduction
• What is Software?
• Software is more than just a program code.

• A program is an executable code, which serves some computational
purpose.
• Software is considered to be collection of executable programming
code, associated libraries and documentations.
• Software, when made for a specific requirement is called software
product
Introduction
• What is Software?
• Software can be:

• Generic:- Developed to be sold to a range of variety of customers
eg.: Excel, Word
• Custom:- Developed for a specific customer according to customers

need
eg.: MIS of Nirma University
Introduction
• Why Software?
• Economies of a country has a major dependency on software.
• Nowadays, more and more systems are software controlled.
• Expenditure on development of software's for automations is a prime
focus for Governments.
Introduction
• What is Software Engineering?
• Software engineering is associated with development of software

product using well-defined scientific principles, methods and
procedures.
• The outcome of software engineering is an efficient and reliable
software product.
• To succeed, we need discipline when software is designed and built
i.e an engineering approach.
• Concerned with theories, practices, methodologies & tools for
professional software development.
Introduction
Introduction
• When a software project succeeds? When it meets the need of

people who will use it, when it performs flawlessly over a long period
of time, when it is easy to modify and even easier to use it etc..
• When a software project does not succeeds? When its users are
dissatisfied, when it is error prone, when it is difficult to modify and
even harder to use etc..
Introduction
• Analogy to understand importance of SE in software

development:
• Let’s think about making a bridge that can connect two places and
the distance between those places is around 10 km.
• List all steps involved in the above task that is required to be
accomplished.
Introduction
• Now the very first thing you will require is requirement gathering then analysis,
feasibility study, planning etc because just manually thinking about this big
project is not going to help you in anyway.
• You have to plan, coordinate and test everything because this project will require
lots of man force with proper budgeting.
• And let’s say you can complete it without any problem then it should be tested
too because it can be dangerous if the bridge is not secure.
• Now same concept comes with making software in companies. You need proper
planning, coordination between people, testing and maintenance too for
software development.
• All these things can be made possible with the help of software engineering.
Introduction
• What if Software Engineering approach not followed?
• For larger systems:
• Requirements collection can be incomplete or not deep enough.
• The lack of methodical, quantifiable methods drives to non-comparable
experience.
• The lack of systematic methods drive to weak or too complex architecture.
• Inconsistent user interface results evident too late to be changed.
• Code will become not easy to maintain.
• No systematic testing strategies drive to omnipresent and never-ending bugs.
• All these calamities can be avoided, for sure, being very careful and experienced.
In most of the cases this implies a strong discipline, following personal rules.
Introduction
• Software Development, Software Engineering, Software
Engineers etc…
• Software development and software engineering are interrelated

terms, but they don’t mean quite the same thing.
• A software engineer is engaged in software development; not all
software developers, however, are engineers.
Introduction
• Software Development, Software Engineering, Software Engineers
etc…
• Software engineering means applying engineering principles to software

creation. It can seem odd to talk about engineering something that doesn’t
have mass or take up space, but software is embedded in things that do
have mass.
• Software does everything from dispense our medication to control large
equipment. Many people also rely on software to perform job duties,
whether they work in an office or telecommute.
• As we all know, software applications can malfunction. It’s not just
bridges that crash… and it’s not just bridges that need a good foundations.
Introduction
Engineers etc…
• Software engineers begin with a thorough study of requirements.

• They work through the development process in a systematic way; this
is called the software development life cycle.
• A software engineer, or programmer, writes software (or changes
existing software) and compiles software using methods that make
it better quality.
Introduction
Engineers etc…
• Software development is the process of developing software

through successive phases in an orderly way.
• This process includes not only the actual writing of code but also the
preparation of requirements and objectives, the design of what is to
be coded, and confirmation that what is developed has met
objectives.
Dual Role of Software
• Both a product and a vehicle for delivering a product
• Product
• Delivers computing potential
• Produces, manages, acquires, modifies, display, or transmits
information
• Vehicle
• Supports or directly provides system functionality
• Controls other programs (e.g., operating systems)
• Effects communications (e.g., networking software)
• Helps build other software (e.g., software tools)
Dual Role of Software
• Few questions to ponder upon:
• Why does it take so long to get software finished?
• Why are development costs so high?
• Why can't we find all errors before we give the software to our
customers?
• Why do we spend so much time and effort maintaining existing
programs?
• Why do we continue to have difficulty in measuring progress as
software is being developed and maintained?
Software:
• Instructions (computer programs) that when executed provide
desired features, function, and performance
• Data structures that enable the programs to adequately manipulate

information
• Documents that describe the operation and use of the programs

Software Characteristics:
• Software is developed or engineered; it is not manufactured in the
classical sense
• Impacts the management of software projects
• Software doesn't wear out

• Hardware bathtub curve compared to the software ascending
spiked curve
• Bath tub curve
• Bath tub curve
• The above graph depicts failure rate as a function of time for
hardware.
• It indicates that hardware exhibits relatively high failure rates early in
its life
• i.e design or manufacturing defects, defects once corrected then
failure rate drops to a steady state level for some period of time.
• As time passes, failure rate rises again due to wear and tear in
hardware components i.e hardware begins to wear out
• Bath tub curve
• Software is not susceptible to environmental maladies

• In theory the failure rate curve for software should be of the form of
idealized curve as shown in previous figure.
• Software does not wear out but it deteriorates
• Software will under go change (maintenance)
• As changes are made it is likely that some new defects will be
introduced (Spike represents the same)
• Hardware component wears out and can be replaced
• There are no software spare parts i.e every software failure indicates:
• An error in design or in the process through which the design was
translated to a machine code
Changing Nature of Software
• System software
• Application software
• Engineering/scientific software
• Embedded software
• Product-line software (e.g., inventory control, word processing, multimedia)
• Web applications
• Artificial intelligence software
• Ubiquitous computing (small, wireless devices)
• Netsourcing (net-wide computing)
• Open source (operating systems, databases, development environments) etc…
Software Myths
Software Myths - Management
• "We already have a book that is full of standards and procedures for
building software. Won't that provide my people with everything
they need to know?“
• Not used, not up to date, not complete, not focused on quality,

time, and money
Software Myths - Management
• "If we get behind, we can add more programmers and catch up“
• Adding people to a late software project makes it more late

• Training time, increased communication lines
• "If I decide to outsource the software project to a third party, I can

just relax and let that firm build it"
• Software projects need to be controlled and managed

Software Myths - Customer
• "A general statement of objectives is sufficient to begin writing

programs – we can fill in the details later"
• Ambiguous statement of objectives spells disaster
• "Project requirements continually change, but change can be easily

accommodated because software is flexible"
• Impact of change depends on where and when it occurs in the

software life cycle (requirements analysis, design, code, test)
Software Myths - Practitioner
• "Once we write the program and get it to work, our job is done"
• 60% to 80% of all effort expended on software occurs after it is

delivered
• "Until I get the program running, I have no way of assessing its

quality
• Formal technical reviews of requirements analysis documents,
design documents, and source code (more effective than actual
testing)
Software Myths - Practitioner
• "The only deliverable work product for a successful project is the

working program"
• Software, documentation, test drivers, test results
• "Software engineering will make us create voluminous and

unnecessary documentation and will invariably slow us down"
• Creates quality, not documents; quality reduces rework and

provides software on time and within the budget
Software Layered Architecture
Software Engineering
• It is a layered technology:
Tools
Methods
Processes
Quality Focus
Software Engineering: Layered Technology
• Any engineering approach (including software engineering) must
rest on an organizational commitment to quality.
• The bedrock that supports software engineering is a quality focus.
• The foundation for software engineering is the process layer.

• It is the glue that holds the technology layers together and enables rational
and timely development of computer software.
• What is a Software Process?
• A set of activities, methods, practices, and transformations that

people use to develop and maintain software and the associated
products (e.g., project plans, design documents, code, test cases, and
user manuals)
• As an organization matures, the software process becomes better
defined and more consistently implemented throughout the
organization
• Software process maturity is the extent to which a specific process is
explicitly defined, managed, measured, controlled, and effective
• (Webster) A system of operations in producing something; a series of
actions, changes, or functions that achieve an end or a result
• (IEEE) A sequence of steps performed for a given purpose

• The Process defines a framework for a set of key process areas (KPAs)
that must be established for effective delivery of software engineering
technology.
• The key process areas form the basis for management control of
software projects.
• It establish the context in which technical methods are applied, work

products (models, documents, data, reports, forms, etc.) are
produced, milestones are established, quality is ensured, and change
is properly managed.
• Software engineering methods provide the technical how-to's for
building software.
• Methods encompass a broad array of tasks that include requirements

analysis, design, program construction, testing, and support.
• Software engineering methods rely on a set of basic principles that

govern each area of the technology and include modeling activities
and other descriptive techniques.
• Software engineering tools provide 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, a system for the support of software
development, called computer-aided software engineering, is
established.
• CASE combines:
• software, hardware, and a software engineering database (a
repository containing important information about analysis, design,
program construction, and testing)
• It creates a software engineering environment
• Eg.: ArgoUML, Rational Rose

• http://www.umsl.edu/~sauterv/analysis/F08papers/View.html
Software Process:
• A software process can be characterized as:
Software Process:
• A common process framework is established by defining a small
number of framework activities that are applicable to all software
projects, regardless of their size or complexity.
• A number of task sets—each a collection of software engineering

work tasks, project milestones, work products, and quality assurance
points—enable the framework activities to be adapted to the
characteristics of the software project and the requirements of the
project team.
Software Process:
• Finally, umbrella activities—such as software quality assurance,
software configuration management, and measurement—overlay the
process model.
• Umbrella activities are independent of any one framework activity
and occur throughout the process.
Generic Process Framework for SE
• Communication
• Involves communication among the customer and other stake

holders; encompasses requirements gathering
• Planning
• Establishes a plan for software engineering work; addresses
technical tasks, resources, work products, and work schedule
• Modeling (Analyze, Design)
• Encompasses the creation of models to better understand the
requirements and the design
• Construction (Code, Test)

• Combines code generation and testing to uncover errors
• Deployment
• Involves delivery of software to the customer for evaluation and
feedback
• Umbrella Activities
• Software requirements management

• Software project planning
• Software project tracking and oversight
• Software quality assurance
• Umbrella Activities
• Software configuration management
• Software subcontract management
• Formal technical reviews
• Risk management
• Measurement – process, project, product
• Reusability management (component reuse)
• Work product preparation and production
Project visibility
Project visibility
• Unlike other engineers (e.g. civil, electronic, chemical … etc.)
software engineers do not produce anything physical.
• It is inherently difficult to monitor an SE project due to lack of
visibility.
• This means that SE projects must produce additional deliverables

(artifacts) which are visible, such as:
• • Design documents/ prototypes • Reports • Project/status meetings •
Client surveys (e.g. satisfaction level)
Process Models
• To solve actual problems in an industry setting, a software engineer
or a team of engineers must incorporate a development strategy that
encompasses the process, methods, and tools layers described in SE
as layered technology concept and the generic SE process.
• This strategy is often referred to as a process model or a software

engineering paradigm.
• A process model for software engineering is chosen based on the
nature of the project and application, the methods and tools to be
used, and the controls and deliverables that are required
Process Models
• A (software/system) process model is a description of the sequence of
activities carried out in an SE project, and the relative order of these
activities.
• CPMCD sequence
• It provides a fixed generic framework that can be tailored to a specific
project.
• Project specific parameters will include: • Size, (person-years) •
Budget, • Duration.
• project plan = process model + project parameters
Process Models
• Planning with Models:
• Why Planning required?
• SE projects usually live with a fixed financial budget .(An exception
is maintenance?)
• Additionally, time-to-market places a strong time constraint.
• There will be other project constraints such as staff, resources etc.
• Each projects have CONSTRAINTS.
• What type of Constraints?
Process Models
Process Models
• Planning with Models:
• Project planning is the art of scheduling: constraint, solving the
project parameters, along various dimensions: time, money, staff …
• in order to optimise: • project risk [low] (see later) • profit [high] •

customer satisfaction [high] • worker satisfaction [high] • full fill
long/short-term company goals
Process Models
• Project parameters describe the whole project, but we must at least
describe:
• resources needed(people, money, equipment, etc)

• dependency & timing of work(flow graph, work packages)
• rate of delivery (reports, code, etc)
• It is impossible to measure rate of progress except with reference to

a plan.
Process Models
• In addition to project members, the following may need access to
parts of the project plan:
• Management
• Customers
• Subcontractors (outsourcing)
• Suppliers (e.g. licenses, strategic partners)
• Investors (long term investment)
• Banks (short term cash)
Process Models
• Example Process Models:
• Waterfall
• Spiral
• Incremental
• Prototyping etc…
Process Models
• By changing the process model, we can improve :
• Development speed (time to market)
• Product quality
• Project visibility
• Administrative overhead
• Risk exposure
• Customer relations, etc, etc.
Process Models
• THE LINEAR SEQUENTIAL MODEL:
• Sometimes called the classic life cycle or the waterfall model, the
linear sequential model suggests a systematic, sequential approach to
software development that begins at:
• the system level and progresses through analysis, design, coding,
testing, and support.
Process Models
Process Models: THE LINEAR SEQUENTIAL MODEL:
• System/information engineering and modeling
• software is always-
• part of a larger system (or business), work begins by establishing

requirements for
• all system elements and then allocating some subset of these

requirements.
• System/information engineering and modeling
• This system view is essential when software must interact with other
elements-
• such as hardware, people, and databases.
• System engineering and analysis encompass-
• requirements gathering at the system level with a small amount of

top level design and analysis.
• Software requirements analysis
• To understand the nature of the program(s)to be built, the software
engineer ("analyst") must:
• understand the information domain for the software, as well as

required function, behavior, performance, and interface.
• Design
• a multistep process that focuses on four distinct attributes of a

program: data structure, software architecture, interface
representations, and procedural (algorithmic) detail.
• The design process translates requirements into a representation of
the software that can be assessed for quality before coding begins.
• Like requirements, the design is documented and becomes part of
the software configuration.
• Code generation
• The design must be translated into a machine-readable form.
• The code generation step performs this task. If design is performed in

a detailed manner, code generation can be accomplished
mechanistically.
• Testing:
• Once code has been generated, program testing begins.
• The testing process
• focuses on the logical internals of the software, ensuring that all
statements have been tested,
• and on the functional externals; that is, conducting tests to uncover
errors and ensure that defined input will produce actual results that
agree with required results.
• Problems with such an approach:
• Real projects rarely follow the sequential flow that the model
proposes.
• Although the linear model can accommodate iteration, it does so
indirectly.
• As a result, changes can cause confusion as the project team
proceeds.
• It is often difficult for the customer to state all requirements

explicitly.
• The linear sequential model requires this and has difficulty

accommodating the natural uncertainty that exists at the beginning
of many projects.
• The customer must have patience.
• A working version of the program(s) will not be available until late in

the project time-span.
• A major blunder, if undetected until the working program is

reviewed, can be disastrous.
• Advantages:
• Easy to understand and implement.

• Widely used and known (in theory!)
• Fits other engineering process models: civil, mech etc.
• Reinforces good habits: define-before- design, designbefore-code
• Identifies deliverables and milestones
• Document driven: People leave, documents don’t
• Works well on large/mature products and weak teams.
• An interesting analysis of actual projects working on this model
states:
• the linear nature of the classic life cycle leads to “blocking states” in
which some project team members must wait for other members of
the team to complete dependent tasks.
• In fact, the time spent waiting can exceed the time spent on
productive work!
• The blocking state tends to be more prevalent at the beginning and
end of a linear sequential process.
Process Models: THE PROTOTYPING MODEL
• Often, the customer:
• defines a set of general objectives for software but does not identify
detailed input, processing, or output requirements.
• In other cases, the developer may be unsure of the efficiency of an

algorithm, the adaptability of an operating system, or the form that
human/machine interaction should take.
• In such cases a prototyping paradigm may offer the best approach.

• Process followed in this approach:
• begins with requirements gathering.
• Developer and customer meet and define the overall objectives for
the software, identify whatever requirements are known, and outline
areas where further definition is mandatory.
• A "quick design" then occurs.
• The quick design focuses on a representation of those aspects of the
software that will be visible to the customer/user (e.g.,input
approaches and output formats).
• When your customer has a legitimate need but is clueless about the
details, develop a prototype as a first step.
• Ideally, the prototype serves as a mechanism for identifying software
requirements.
• If a working prototype is built, the developer attempts to use existing
program fragments or applies tools (e.g., report generators, window
managers) that enable working programs to be generated quickly.
• But, what to do with the prototype when it has served the purpose we
just discussed?
• In most projects, the first system built is barely usable. It may be too
slow, too big, awkward in use or all three.
• There is no alternative but to start again, smarting but smarter, and
build a redesigned version in which these problems are solved . . .
• When a new system concept or new technology is used, one has to
build a system to throw away, for even the best planning is not so
omniscient as to get it right the first time.
• The management question, therefore, is not whether to build a pilot
system and throw it away. You will do that. The only question is
whether to plan in advance to build a throwaway, or to promise to
deliver the throwaway to customers .
• Advantages:
• The prototype can serve as "the first system, using which user gets a
feel for the actual system and on other hand developers get to build
something immediately.
• Reduces risk of failure on a larger scale.
• List the shortfalls of Prototyping Model?
• Shortfalls of Prototyping Model:
• The customer sees what appears to be a working version of the
software, unaware that the prototype is held together just for a
temporary phase.
• In the rush to get a working prototype working no one considers
overall software quality or long-term maintainability.
• When management informs that the product must be rebuilt so that
high levels of quality can be maintained, the customer cries foul and
demands that "a few fixes" be applied to make the prototype a
working product.
• Too often, software development management relents.
• Shortfalls of Prototyping Model:
• The developer often makes implementation compromises in order to
get a prototype working quickly.
• An inappropriate operating system or programming language may be
used simply because it is available and known; an inefficient
algorithm may be implemented simply to demonstrate capability.
• After a time, the developer may become familiar with these choices
and forget all the reasons why they were inappropriate.
• The less-than-ideal choice has now become an integral part of the
system.
• Although problems can occur, prototyping can be an effective
paradigm for software engineering.
• The key is to define the rules of the game at the beginning; that is,
the customer and developer must both agree that the prototype is
built to serve as a mechanism for defining requirements and
validating those.
• It is then discarded (at least in part) and the actual software is

engineered with an eye toward quality and maintainability
Process Models: THE RAD MODEL
• Rapid application development (RAD) is an incremental software
development process model that emphasizes an extremely short
development cycle.
• The RAD model is a “high-speed” adaptation of the linear sequential

model in which rapid development is achieved by using component-
based construction.
• If requirements are well understood and project scope is constrained,

the RAD process enables a development team to create a “fully
functional system” within very short time periods (e.g., 60 to 90
days).
• Used primarily for information systems applications, the RAD
approach encompasses the following phases:
• Business modeling
• Data modeling
• Process modeling
• Application generation
• Testing and turnover
• Business modeling:
• The information flow among business functions is modelled in a way
that answers the following questions:
• What information drives the business process?
• What information is generated? Who generates it? Where does the

information go?
• Who processes it? Business modeling is described in more detail in

further chapters.
• Data modeling:
• The information flow defined as part of the business modeling phase
is refined into a set of data objects that are needed to support the
business.
• The characteristics (called attributes) of each object are identified
and the relationships between these objects defined.
• Data modeling will be discussed further.
• Process modeling:
• The data objects defined in the data modeling phase are transformed
to achieve the information flow necessary to implement a business
function.
• Processing descriptions are created for adding, modifying, deleting,
or retrieving a data object.
• Application generation:
• RAD assumes the use of fourth generation techniques.
• Rather than creating software using conventional programming
languages the RAD process works to reuse existing program
components (when possible) or create reusable components (when
necessary).
• In all cases, automated tools are used to facilitate construction of the
software.
• Testing and turnover:
• As RAD emphasizes on reuse, reusable components are already
tested.
• This reduces overall testing time. However, new components must be
tested and all interfaces must be fully exercised.
• The time constraints imposed on a RAD project demand “scalable
scope”.
• If a business application can be modularized in a way that enables

each major function to be completed in less than three months
(using the approach described previously), it is a candidate for RAD.
• Each major function can be addressed by a separate RAD team and

then integrated to form a whole.
• Identify shortfalls of RAD?
• Shortfalls of RAD
• For large but scalable projects, RAD requires sufficient human
resources to create the right number of RAD teams.
• RAD requires developers and customers who are committed to the
rapid-fire activities necessary to get a system complete in a much
abbreviated time frame.
• If commitment is lacking from either constituency, RAD projects will
fail.
• Shortfalls of RAD
• Not all types of applications are appropriate for RAD. If a system
cannot be properly modularized, building the components necessary
for RAD will be problematic.
• If high performance is an issue and performance is to be achieved
through tuning the interfaces to system components, the RAD
approach may not work.
• Recall the previous process models discussed.
• Did you observe any common key aspect in those process models in
context to software development?
Process Models: EVOLUTIONARY SOFTWARE PROCESS MODELS
• There is growing recognition that software, like all complex systems,
evolves over a period of time.
• Business and product requirements often change as development
proceeds, making a straight path to an end product unrealistic; tight
market deadlines make completion of a comprehensive software
product impossible, but a limited version must be introduced to
meet competitive or business pressure; a set of core product or system
requirements is well understood, but the details of product or system
extensions have yet to be defined.
• In these and similar situations, software engineers need a process
model that has been explicitly designed to accommodate a product
that evolves over time.
• The linear sequential model is designed for straight-line
development.
• In essence, this waterfall approach assumes that a complete system
will be delivered after the linear sequence is completed.
• The prototyping model is designed to assist the customer (or
developer) in understanding requirements.
• In general, it is not designed to deliver a production system. The
evolutionary nature of software is not considered in either of these
classic software engineering paradigms.
• Evolutionary models are iterative.
• They are characterized in a manner that enables software engineers

to develop increasingly more complete versions of the software.
Process Models: THE INCREMENTAL MODEL
• The incremental model combines elements of the linear sequential
model (applied repetitively) with the iterative philosophy of
prototyping.
• The incremental model applies linear sequences in a staggered
fashion as calendar time progresses.
• Each linear sequence produces a deliverable “increment” of the

software.
• Any example system that can be developed using this approach?

• For example, word-processing software developed using the
incremental paradigm might deliver basic file management, editing,
and document production functions in the first increment.
• More sophisticated editing and document production capabilities in
the second increment.
• Spelling and grammar checking in the third increment; and
advanced page layout capability in the fourth increment.
• It should be noted that the process flow for any increment can
incorporate the prototyping paradigm.
• Identify the key aspect of such approach?
• When an incremental model is used, the first increment is often a
core product. That is, basic requirements are addressed, but many
supplementary features (some known, others unknown) remain
undelivered.
• The core product is used by the customer (or undergoes detailed
review). As a result of use and/or evaluation, a plan is developed for
the next increment.
• The plan addresses the modification of the core product to better
meet the needs of the customer and the delivery of additional
features and functionality.
• This process is repeated following the delivery of each increment,
until the complete product is produced.
• Compare prototying model with incremental approach?
• The incremental process model, like prototyping and other
evolutionary approaches, is iterative in nature.
• But unlike prototyping, the incremental model focuses on the
delivery of an operational product with each increment.
• Early increments are stripped down versions of the final product, but
they do provide capability that serves the user and also provide a
platform for evaluation by the user.
• Advantages of using Incremental process model approach?
• Incremental development is particularly useful when staffing is
unavailable for a complete implementation by the business deadline that
has been established for the project.
• Early increments can be implemented with fewer people. If the core
product is well received, then additional staff (if required) can be added to
implement the next increment.
• In addition, increments can be planned to manage technical risks. For
example, a major system might require the availability of new hardware
that is under development and whose delivery date is uncertain.
• It might be possible to plan early increments in a way that avoids the use of
this hardware, thereby enabling partial functionality to be delivered to
end-users without inordinate delay.
• The Spiral Model
• The spiral model, originally proposed by Boehm, is an evolutionary
software process model that couples the iterative nature of
prototyping with the controlled and systematic aspects of the linear
sequential model.
• It provides the potential for rapid development of incremental
versions of the software.
• Using the spiral model, software is developed in a series of
incremental releases. During early iterations, the incremental release
might be a paper model or prototype.
• During later iterations, increasingly more complete versions of the
engineered system are produced.
• A spiral model is divided into a number of framework activities, also
called task regions.
• Typically, there are between three and six task regions.
• Figure in next slide depicts a spiral model that contains six task
regions:
Process Models: TE INCREMENTAL MODEL
• Customer communication—tasks required to establish effective
communication between developer and customer.
• Planning—tasks required to define resources, timelines, and other
project related information.
• Risk analysis—tasks required to assess both technical and
management risks.
• Engineering—tasks required to build one or more representations
of the application.
• Construction and release—tasks required to construct, test, install,
and provide user support (e.g., documentation and training).
• Customer evaluation—tasks required to obtain customer feedback
based on evaluation of the software representations created during
the engineering stage and implemented during the installation stage.
• Post Lecture Task:
• Study the Spiral Model diagram and identify the basic working
of the model.
• The Spiral Model:
• The spiral model combines the idea of iterative development with the
systematic, controlled aspects of the waterfall model.
• It allows for incremental releases of the product, or incremental

refinement through each iteration around the spiral.
• Each of the regions is populated by a set of work tasks, called a task
set, that are adapted to the characteristics of the project to be
undertaken.
• For small projects, the number of work tasks and their formality is
low.
• For larger, more critical projects, each task region contains more
work tasks that are defined to achieve a higher level of formality.
• In all cases, the umbrella activities (e.g., software configuration
management and software quality assurance) are applied.
• As this evolutionary process begins, the software engineering team
moves around the spiral in a clockwise direction, beginning at the
center.
• The first circuit around the spiral might result in the development of
a product specification;
• subsequent passes around the spiral might be used to develop a

prototype and then progressively more sophisticated versions of the
software.
• Each pass through the planning region results in adjustments to the
project plan.
• Cost and schedule are adjusted based on feedback derived from
customer evaluation.
• In addition, the project manager adjusts the planned number of
iterations required to complete the software.
• Can you interpret any other view point or perspective for the
Spiral Model By again referring the diagram?
• The Spiral Model: {A different View point}
• Unlike classical process models that end when software is delivered,
the spiral model can be adapted to apply throughout the life of the
computer software.
• An alternative view of the spiral model can be considered by

examining the project entry point axis, also shown in Figure.
• Each cube placed along the axis can be used to represent the starting
point for different types of projects.
• A “concept development project” starts at the core of the spiral and
will continue (multiple iterations occur along the spiral path that
bounds the central shaded region) until concept development is
complete.
• If the concept is to be developed into an actual product, the process

proceeds through the next cube (new product development project
entry point) and a “new development project” is initiated.
• The new product will evolve through a number of iterations around
the spiral, following the path that bounds the region that has
somewhat lighter shading than the core.
• In essence, the spiral, when characterized in this way, remains

operative until the software is retired.
• There are times when the process is dormant, but whenever a change
is initiated, the process starts at the appropriate entry point (e.g.,
product enhancement).
• The spiral model is a realistic approach to the development of large-
scale systems and software.
• Because software evolves as the process progresses, the developer and

customer better understand and react to risks at each evolutionary
level.
• The spiral model uses prototyping as a risk reduction mechanism

but, more important, enables the developer to apply the prototyping
approach at any stage in the evolution of the product.
• It maintains the systematic stepwise approach suggested by the
classic life cycle but incorporates it into an iterative framework that
more realistically reflects the real world.
• Post lecture task: Identify shortfalls of spiral model?

Process Models:
• Component-based software engineering:
• This approach is based on the existence of a significant number of

reusable components.
• The system development process focuses on integrating these
components into a system rather than developing them from scratch.
• In the majority of software projects, there is some software reuse.
• This usually happens informally when people working on the project
know of designs or code which is similar to that required. They look
for these, modify them as needed and incorporate them into their
system.
Process Models:
Process Models:
• The initial requirements specification stage and the validation stage
are comparable with other processes we discussed.
• The intermediate stages in a reuse-oriented process are different.
• These stages are discussed in next slides:

Process Models:
• 1. Component analysis Given the requirements specification, a
search is made for components to implement that specification.
Usually, there is no exact match, and the components that may be
used only provide some of the functionality required.
• 2. Requirements modification During this stage, the requirements

are analysed using information about the components that have been
discovered. They are then modified to reflect the available
components. Where modifications are impossible, the component
analysis activity may be re-enteredto search for alternative solutions.
Process Models:
• 3. System design with reuse During this phase, the framework of the
system is designed or an existing framework is reused. The designers
take into account the components that are reused and organise the
framework to cater to this. Some new software may have to be
designed if reusable components are not available.
• 4. Development and integration Software that cannot be externally

procured is developed, and the components are integrated to create
the new system. System integration, in this model, may be part of the
development process rather than a separate activity.
Process Models:
• List advantages and shortfalls of Component based software
engineering approach?
Process Models: Component-based software engineering:
• Advantages & shortfalls of Component based software

engineering approach:
• Reducing the amount of software to be developed and so reducing
cost and risks.
• It usually also leads to faster delivery of the software.
• Requirements compromises are inevitable and this may lead to a
system that does not meet the real needs of users.
• Furthermore, some control over the system evolution is lost as new
versions of the reusable components are not under the control of the
organisation using them
Process Models: The Rational Unified Process
• The RUP recognises that conventional process models present a
single view of the process.
• In contrast, the RUP is normally described from three perspectives:
• I. A dynamic perspective that shows the phases of the model over
time.
• 2. A static perspective that shows the process activities that are
enacted.
• 3. A practice perspective that suggests good practices to be used
during the process.
• The RUP is a phased model that identifies four discrete phases in the
software process.
• However, unlike the waterfall model where phases are equated with
process activities, the phases in the RUP are more closely related
to business rather than technical concerns.
• Business goals are at the centre

• Inception:
• The goal of the inception phase is to establish a business case for the
system.
• You should identify all external entities (people and systems) that will
interact with the system and define these interactions.
• You then use this information to assess the contribution that the
system makes to the business.
• If this contribution is minor, then the project may be cancelled after
this phase.
• Elaboration:
• The goals of the elaboration phase are to develop an understanding of

the problem domain, establish an architectural framework for the
system, develop the project plan and identify key project risks.
• On completion of this phase. you should have a requirements model

for the system (UML use cases are specified), an architectural
description and a development plan for the software.
• Construction:
• The construction phase is essentially concerned with system design,

programming and testing.
• Parts of the system are developed in parallel and integrated during

this phase.
• On completion of this phase, you should have a working software
system and associated documentation that is ready for delivery to
users.
• Transition:
• The final phase of the RUP is concerned with moving the system from
the development community to the user community and making it
work in a real environment.
• This is something that is ignored in most software process models but

is, in fact, an expensive and sometimes problematic activity.
• On completion of this phase, you should have a documented software

system that is working correctly in its operational environment.
• Static workflows in Rational Unified Process:
PROCESS ACTIVITIES
PROCESS ACTIVITIES: Software specification
• In-Lecture Task:
• Assume you have an opportunity to open a food stall at Nirma

in an event NuTech, being the owner list all steps you will
perform before booking the stall and for achieving success
later on.
• Assume you have an opportunity to open a game zone stall at

Nirma in an event NuTech, being the owner list all steps you
will perform before booking the stall and for achieving success
later on.
PROCESS ACTIVITIES
• The four basic process activities of specification, development,
validation and evolution are organised differently in different
development processes.
• In the waterfall model, they are organised in sequence, whereas in

evolutionary development they are interleaved.
• How these activities are carried out depends on the type of software,
people and organisational structures involved.
• There is no right or wrong way to organise these activities.

• Software specification or requirements engineering is:
• The process of understanding and defining,
• What services are required from the system and identifying the
constraints on the system's operation and development
• Requirements engineering is a particularly critical stage of the
software process as errors at this stage inevitably lead to later
problems in the system design and implementation.
• There are four main phases in the requirements engineering process:
• Feasibility Study
• Requirements elicitation & analysis
• Requirements specification
• Requirements validation
• Feasibility Study
• An estimate is made of whether the identified user needs may be
satisfied using current software and hardware technologies.
• The study considers whether the proposed system will be cost-

effective from a business point of view and whether it can be
developed within existing budgetary constraints.
• A feasibility study should be relatively cheap and quick. The result

should inform the decision of whether to go ahead with a more
detailed analysis.
• Requirements elicitation and analysis
• This is the process of deriving the system requirements through
observation of existing systems, discussions with potential users and
procurers etc.
• This may involve the development of one or more system models and
prototypes.
• This helps the analyst understand the system to be specified.
• Requirements specification
• The activity of translating the information gathered during the
analysis activity into a document that defines a set of requirements.
• Two types of requirements may be included in this document.
• User requirements are abstract statements of the system

requirements for the customer and end-user of the system;
• System requirements are a more detailed description of the
functionality to be provided.
SRS
Technically Speaking,
"requirement" ≠ "specification“
• Requirement – understanding between customer and supplier
• Specification – what the software must do
Lecture Task
[1] Giving reasons for your answer based on the type of system being
developed, suggest the most appropriate generic software process
model that might be used as a basis for managing the development of
the following systems:
• A system to control anti-lock braking in a car
• A virtual reality system to support software maintenance
• A university accounting system that replaces an existing system
• An interactive system that allows railway passengers to find train
times from terminals installed in stations.
Lecture Task
[2] “Both the waterfall model of the software process and the
prototyping model can be accommodated in the spiral process model.”
Justify with appropriate example.
[3] “It is important to make a distinction between developing the user

requirements and developing system requirements in the
requirements engineering process.” Justify with appropriate example.
[4] Define software engineering. Explain the different types of software

products.
Lecture Task
[5] Differentiate generic and customized software products.
[6] You have been appointed as a project manager within a software

company. Your job is to build an application that is quite similar to
others your team has built in the past, although this new one to be
built is larger and more complex system compared to the ones your
team developed in past. Requirement have been documented
thoroughly for the new system to be developed. Which process model
would you choose and why?
Lecture Task
[7] You have been appointed as a project manager within a software
company. Your job is to manage the development of the next
generation version of its widely used word-processing software.
Because competition is intense in the market, tight deadlines have
been established and announced. Which process model would you
choose and why?
• Requirements validation
• This activity checks the requirements for realism, consistency and
completeness.
• During this process, errors in the requirements document are

inevitably discovered.
• It must then be modified to correct these problems.

PROCESS ACTIVITIES: Software design and implementation
• The implementation stage of software development is the process of
converting a system specification into an executable system.
• It always involves processes of software design and programming but,

if an evolutionary approach to development is used, may also involve
refinement of the software specification.
• A software design is a description of the structure of the software to
be implemented, the data which is part of the system, the interfaces
between system components and, the algorithms used.
• Designers do not arrive at a finished design immediately but develop

the design iteratively through a number of versions.
• The design process involves adding formality and detail as the design
is developed with constant backtracking to correct earlier designs.
• The specific design process activities are:
• Architectural design: The sub-systems making up the system and
their relationships are identified and documented.
• Abstract specification: For each sub-system, an abstract specification

of its services and the constraints under which it must operate is
produced.
• Interface design: For each sub-system, its interface with other sub-
systems is designed and documented.
• Component design Services are allocated to components and the
interfaces of these components are designed.
• Data structure design: The data structures used in the system

implementation are designed in detail and specil1ed.
• Algorithm design: The algorithms used to provide services are

designed in detail and specified.
PROCESS ACTIVITIES: Software validation
• Software validation or, more generally, verification and validation (V
& V) is intended to show that a system conforms to its specification
and that the system meets the expectations of the customer buying
the system.
• It involves checking processes, such as inspections and reviews at

each stage of the software process from user requirements definition
to program development.
• The majority of validation costs, however, are incurred after

implementation when the operational system is tested.
• The stages in the testing process are:
• Component (or unit) testing: Individual components are tested to
ensure that they operate correctly.
• Each component is tested independently, without other system

components.
• Components may be simple entities such as functions or object

classes, or may be coherent groupings of these entities.
• System testing: The components are integrated to make up the
system.
• This process is concerned with finding errors that result from

unanticipated interactions between components and component
interface problems.
• For large systems, this may be a multistage process where

components are integrated to form sub-systems that are individually
tested before they are themselves integrated to form the final system.
• Acceptance testing: This is the final stage in the testing process before
the system is accepted for operational use.
• The system is tested with data supplied by the system customer
rather than with simulated test data.
• Acceptance testing may reveal errors and omissions in the system
requirements definition because the real data exercise the system in
different ways from the test data.
• Acceptance testing may also reveal requirements problems where the
system's facilities do not really meet the user s needs or the system
performance is unacceptable.
PROCESS ACTIVITIES: Software evolution
• The flexibility of software systems is one of the main reasons why
more and more software is being incorporated in large, complex
systems.
• Once a decision has been made to procure hardware, it is very
expensive to make changes to the hardware design.
• However, changes can be made to software at any time during or after
the system development.
• Even extensive changes are still much cheaper than corresponding
changes to system hardware.
Computer-Aided Software Engineering
• Computer-Aided Software Engineering (CASE) is the name given to
software used to support software process activities such as
requirements engineering, design, program development and testing.
• CASE tools therefore include design editors, data dictionaries,

compilers, debuggers, system building tools and so on.
• CASE technology provides software process support by automating

some process activities and by providing information about the
software that is being developed.
• Post Lecture Task: Identify various CASE tools and classify
them according to various process activitities.
PROJECT MANAGEMENT CONCEPTS
The Management Spectrum
• Effective software project management focuses on the four P’s:
people, product, process, and project.
• The order is not arbitrary.
• The manager who forgets that software engineering work is an

intensely human endeavor will never have success in project
management.
The Management Spectrum
• A manager who fails to encourage comprehensive customer
communication early in the evolution of a project risks building an
elegant solution for the wrong problem.
• The manager who pays little attention to the process runs the risk of
inserting competent technical methods and tools into a vacuum.
• The manager who embarks without a solid project plan jeopardizes

the success of the product.
The Management Spectrum: The People
• There exists enormous variability in the ability of different people to
perform various tasks involved in a product development.
• The “people factor” is so important that the Software Engineering

Institute has developed a people management capability maturity
model (PM-CMM), to:
• Enhance the readiness of software organizations to undertake
increasingly complex applications by helping to attract, grow,
motivate, deploy, and retain the talent needed to improve their
software development capability.
The Management Spectrum: The People
• The people management maturity model defines the following key
practice areas for software people: recruiting, selection, performance
management, training, compensation, career development,
organization and work design, and team/culture development.
• Organizations that achieve high levels of maturity in the people

management area have a higher likelihood of implementing effective
software engineering practices.
The Management Spectrum: The Product
• Before a project can be planned, product objectives and scope should
be established, alternative solutions should be considered, and
technical and management constraints should be identified.
• Without this information:
• it is impossible to define reasonable (and accurate) estimates of the

cost, an effective assessment of risk, a realistic breakdown of project
tasks, or a manageable project schedule that provides a meaningful
indication of progress
The Management Spectrum:
• To complete a project:
• On Time
• On budget
• With required functionality
• To the satisfaction of the client
• Without exhausting the team
To provide visibility about the progress of a project is a critical aspect

The Management Spectrum:
• List Challenges of Project Management
The Management Spectrum: Challenges of Project Management
• Clients wish to know:
• Will the system do what was promised?

• When will it be delivered?
• If late, how late?
• How does the cost compare with the budget?
• Often the software is part of a larger ac1vity
• If the system is a product, marketing and development must be

combined (e.g., Microsoft Office)
• If the system has to work with other systems, developments must be

coordinated (e.g., embedded systems in an automobile)
• BUT:
• Every software system is different.
• Most systems are not well specified, or the requirements change
during development.
• Estimating time and effort can be prone to errors, even when the
system is well understood.
• So, the Management plays an integral role in Software development

The Management Spectrum: People
• “Companies that sensibly manage their investment in people will

prosper in the long run.” By Tom DeMarco & Tim Lister
• In a study published by the IEEE , the engineering vice presidents of

three major technology companies were asked the most important
contributor to a successful software project.
• They answered in the following way:
• VP 1: I guess if you had to pick one thing out that is most

important in our environment, I'd say it's not the tools that we
use, it's the people.
• VP 2: The most important ingredient that was successful on this

project was having smart people . . . very little else matters in
my opinion. . . .
• The most important thing you do for a project is selecting the

staff . . .
• The success of the software development organization is very,

very much associated with the ability to recruit good people.
• VP 3: The only rule I have in management is to ensure I have

good people—real good people—and that I grow good people—
and that I provide an environment in which good people can
produce.
• List categorically The Players involved in Software Project

The Management Spectrum: People {Players}
• Players involved in SE can be categorized into five constituencies:

• 1. Senior managers who define the business issues that often have
significant influence on the project.
• 2. Project (technical) managers who must plan, motivate,

organize, and control the practitioners who do software work.
• 3. Practitioners who deliver the technical skills that are necessary to

engineer a product or application.
• Players involved in SE can be categorized into five constituencies:
• 4. Customers who specify the requirements for the software to be

engineered and other stakeholders who have a peripheral interest in
the outcome.
• 5. End-users who interact with the software once it is released for

production use.
• Every software project is populated by people who fall within this

taxonomy.
• To be effective, the project team must be organized in a way that
maximizes each person’s skills and abilities.
• And for achieving this who has the responsibility?

The Management Spectrum: People {Team Leaders}
• What do we look for when we select someone to lead a software

project?
• In simplest terms, a leader is one who knows where he wants to go,

and gets up, and goes carrying his/her team along the path.
• Team Leaders should provide:
• Motivation: The ability to encourage (by “push or pull”) technical
people to produce to their best ability.
• Organization: The ability to mould existing processes (or invent
new ones) that will enable the initial concept to be translated into a
final product.
• Ideas or innovation: The ability to encourage people to create and
feel creative even when they must work within bounds established
for a particular software product or application.
• Characteristics of a good leader:

• Understanding the problem to be solved
• managing the flow of ideas
• at the same time, letting everyone on the team know (by words and,
far more important, by actions) that quality counts and that it will
not be compromised.
The Management Spectrum: People {The Software Team}
• “Not every group is a team, and not every team is effective.” Glenn
Parker
• What key aspects would you (as a Project Manager) consider while
constituting a software team i.e team composition ?
• The “best” team structure depends on the management style of your

organization, the number of people who will populate the team and
their skill levels, and the overall problem difficulty.
• Mantei [MAN81] suggests three generic team organizations:

• Democratic decentralized (DD)
• Controlled decentralized (CD)
• Controlled Centralized (CC)
• Democratic decentralized (DD)
• This software engineering team has no permanent leader.

• Rather, "task coordinators are appointed for short durations and then
replaced by others who may coordinate different tasks."
• Decisions on problems and approach are made by group consensus.
• Communication among team members is horizontal.
• Controlled decentralized (CD)

• This software engineering team has a defined leader who coordinates
specific tasks and secondary leaders that have responsibility for
subtasks.
• Problem solving remains a group activity, but implementation of
solutions is partitioned among subgroups by the team leader.
• Communication among subgroups and individuals is horizontal.
• Vertical communication along the control hierarchy also occurs.
• Post Lecture Task: Identify & list different scenarios where DD CD

CC generic team organizations will work best. Also list pro’s and con’s
of the generic team organizations.
• Basic seven project factors that should be considered when planning

the structure of software engineering teams:
• Difficulty of problem to be solved

• The size of the resultant program(s) in lines of code {Will be covered
later}
• Team Lifetime
• Degree to which problem can be modularized
• Required quality and reliability of the system to be built
• Rigidity of the delivery date
• Degree of sociability (communication) required for the project.
• Coordination and Communication Issues
• There are many reasons that software projects get into trouble.
• The scale of many development efforts is large, leading to complexity,
confusion, and significant difficulties in coordinating team members.
• Uncertainty is common, resulting in a continuing stream of changes
that ratchets the project team.
• Coordination and Communication Issues
• Interoperability has become a key characteristic of many systems.

• New software must communicate with existing software and conform
to predefined constraints imposed by the system or product.
• To deal with scale, uncertainty & interoperability effectively, a

software engineering team must establish effective methods for
coordinating the people who do the work.
• Coordination and Communication Issues {C&C Issues}
• What can be possible C&C Issues when dealing with a large team?
• What mechanism can be adopted for effective coordination &
Communication among team members to avoid C&C Issues?

• Coordination techniques can be categorized as:
• Formal, impersonal approaches:
• It includes software engineering documents and deliverables
(including source code), technical memos, project milestones,
schedules, and project control tools, change requests and related
documentation, error tracking reports etc..

• Formal, interpersonal procedures:
• It focuses on quality assurance activities applied to software

engineering work products.
• These include status review meetings and design and code
inspections.

• Informal, interpersonal procedures:
• It include group meetings for information dissemination and
problem solving.
• Electronic communication encompasses electronic mail, electronic

bulletin boards, and by extension, video-based conferencing systems.

• Interpersonal networking includes informal discussions with team
members and those outside the project who may have experience or
insight that can assist team members.
The Management Spectrum: People {Product}
• A detailed analysis of software requirements would provide necessary

information for estimates, but analysis often takes weeks or months
to complete.
• Worse, requirements may be fluid, changing regularly as the project
proceeds. Yet, a plan is needed "now!"
• Therefore, we must examine the product and the problem it is
intended to solve at the very beginning of the project.
• At a minimum, the scope of the product must be established and
bounded.
The Management Spectrum: People {Product- Software Scope}
• The first software project management activity is the determination

of software scope.
• Scope is defined by answering the following questions:
• Context. How does the software to be built fit into a larger system,
product, or business context and what constraints are imposed as a
result of the context?
• Information objectives. What customer-visible data objects are

produced as output from the software? What data objects are
required for input?
• The first software project management activity is the determination

of software scope.
• Scope is defined by answering the following questions:
• Function and performance. What function does the software
perform to transform input data into output? Are any special
performance characteristics to be addressed?
• Software project scope must be unambiguous and understandable at

the management and technical levels.
• A statement of software scope must be bounded. That is, quantitative
data (e.g., number of simultaneous users, size of mailing list,
maximum allowable response time) are stated explicitly; constraints
and/or limitations (e.g., product cost restricts memory size) are
noted, and mitigating factors (e.g., desired algorithms are well
understood and available in C++) are described.
• Problem Decomposition:
• Class Activity: You have been assigned a task to clean the entire
campus of NU?
• How will you decompose this problem assigned to you?

• Problem Decomposition
• In order to develop a reasonable project plan, you have to functionally
decompose the problem to be solved.
• Problem decomposition, sometimes called partitioning or problem

elaboration, is an activity that sits at the core of software
requirements analysis.
• During the scoping activity no attempt is made to fully decompose
the problem.
• Rather, decomposition is applied in two major areas:
• (1) the functionality that must be delivered
and
• (2) the process that will be used to deliver it
• During the scoping activity no attempt is made to fully decompose
the problem.
• Rather, decomposition is applied in two major areas:
• (1) the functionality that must be delivered
and
• (2) the process that will be used to deliver it
Software Project Management
• How Software Project Management differs from other types of project

management i.e like managing a civil engineering project, or
electrical engineering project etc..?
• Software engineering is different from other types of engineering in a

number of ways:-
• The software product is intangible:
• The manager of a shipbuilding project or of a civil engineering project

can see the product being developed.
• If a schedule slips, the 'effect on the product is visible-parts of the
structure are obviously unfinished.
• Software is intangible. It cannot be seen or touched.
• Software project managers cannot see progress. They rely on others to
produce the documentation needed to review progress.

number of ways:-
• There are no standard software processes:
• In engineering disciplines with a long history, the process is tried and

tested.
• The engineering process for some types of system, such as bridges and
buildings is well understood.
• However, software processes vary dramatically from one organisation to
another.
• We still cannot reliably predict when a particular software process is
likely to cause development problems.

number of ways:-
• Large software projects are often one-off projects:
• Large software projects are usually different in some ways from previous
projects.
• Therefore, even managers who have a large body of previous experience
may find it difficult to anticipate problems.
• Furthermore, rapid technological changes in computers and
communications can make a managers experience obsolete.
• Lessons learned from previous projects may not be transferable to new
projects.
Software Project Management: Management activities
• It is impossible to write a standard job description for a software

manager.
• The job varies tremendously depending on the organisation and the
software product being developed.
• However, most managers take responsibility at some stage for some
or all of the following activities:
• Proposal writing, Project planning and scheduling, Project costing,

Project monitoring and reviews, Personnel selection and evaluation,
Report writing and presentations
• It is impossible to write a standard job description for a software

manager.
• The job varies tremendously depending on the organisation and the
software product being developed.
• However, most managers take responsibility at some stage for some
or all of the following activities:
• Proposal writing, Project planning and scheduling, Project costing,

Project monitoring and reviews, Personnel selection and evaluation,
Report writing and presentations
• Proposal Writing:
• The first stage in a software project may involve writing a proposal to
win a contract to carry out the work.
• The proposal describes the objectives of the project and how it will be
carried out.
• It usually includes cost and schedule estimates, and justifies why the
project contract should be awarded to a particular organisation or
team.
• proposal writing is a skill that you acquire through practice and
experience.
• Project Planning:
• Effective management of a software project depends on thoroughly
planning the progress of the project.
• Managers must anticipate problems that might arise and prepare
tentative solutions to those problems.
• A plan, drawn up at the start of a project, should be used as the driver
for the project.
• This initial plan should be the best possible plan given the available
information.
• It evolves as the project progresses and better information becomes
available.
Establish the project constraints
Make initial assessments of the project parameters
Define project milestones and deliverables
while project has not been completed or cancelled loop
Draw up project schedule
Initiate activities according to schedule
Wait ( for a while )
Review project progress
Revise estimates of project parameters
Update the project schedule
Renegotiate project constraints and deliverables
If ( problems arise) then
Initiate technical review and possible revision
end It
end loop
• The previous flow shows that planning is an iterative process, which

is only complete when the project itself is complete.
• As project information becomes available during the project, the plan
should be regularly revised.
• The goals of the business are an important factor that must be
considered when formulating the project plan.
• As these change, the project's goals also change so changes to the
project plan are necessary
• Project Plan:
• The project plan sets out the resources available to the project, the
work breakdown and a schedule for carrying out the work.
• In some organisations, the project plan is a single document that
includes the different types of plan.
• The details of the project plan vary depending on the type of project
and organisation.
• However, most plans should include the following sections as
mentioned in next slides.
• Project Plan:
• Introduction- This briefly describes the objectives of the project and
sets out the constraints (e.g., budget, time, etc.) that affect the
project management.
• Project organisation- This describes the way in which the

development team is organised, the people involved and their roles in
the team.
• Risk analysis- This describes possible project risks, the likelihood of

these risks arising and the risk reduction strategies that are proposed.
• Project Plan:
• Hardware and software resource requirements- This specifies the hardware
and the support software required to carry out the development. If
hardware has to be bought, estimates of the prices and the delivery
schedule may be included.
• Work breakdown- This sets out the breakdown of the project into activities
and identifies the milestones and deliverables associated with each
activity.
• Project schedule- This shows the dependencies between activities, the

estimated time required to reach each milestone and the allocation of
people to activities.
• Project Plan:
• Monitoring and reporting mechanisms- This defines the management
reports that should be produced, when these should be produced
and the project monitoring mechanisms used.
• Note: You should regularly revise the project plan during the project.
• Some parts, such as the project schedule, will change frequently;
other parts will be more stable.
• To simplify revisions, you should organise the document into
separate sections that can be individually replaced as the plan
evolves.
• Milestones and deliverables:
• When planning a project, you should establish a series of milestones.

where a milestone is a recognisable end-point of a software process
activity.
• At each milestone, there should be a formal output, such as a report,
that can be presented to management. Milestone reports need not be
large documents.
• They may simply be a short report of what has been completed.
Milestones should represent the end of a distinct, logical stage in the
project.
• Eg: Milestone Coding 80% complete

• Is the above milestone a valid one?
• Eg: Milestone Coding 80% complete

• Not above mentioned is not a valid milestone as You can't check
whether this state has been achieved because the amount of code
that still has to be developed is uncertain.
• A deliverable is a project result that is delivered to the customer. It is
usually delivered at the end of some major project phase such as
specification or design.
• Deliverables are usually milestones, but milestones need not be

deliverables always.
• Milestones may be internal project results that are used by the

project manager to check project progress but which are not
delivered! to the customer.
• To establish milestones, the software process must be broken down into
basic activities with associated outputs.
• The milestones in this case are the completion of the outputs for each
activity. The project deliverables, which are delivered to the customer, are
the requirements definition and the requirements specification.
• Project Scheduling:
• List possible challenges involved in scheduling any project?

• It is one of the most difficult jobs for a project manager. Managers
estimate the time and resources required to complete activities and
organise them into a coherent sequence.
• Unless the project being scheduled is similar to a previous project,

previous estimates are an uncertain basis for new project scheduling.
• Schedule estimation is further complicated by the fact that different

projects may use different design methods and implementation
languages.
• Schedules must be continually updated as better progress
information becomes available.
• Project scheduling involves separating the total work involved in a
project into separate activities and judging the time required to
complete these activities.
• Usually, some of these activities are carried out in parallel. You have
to coordinate these parallel activities and organise the work so that
the workforce is used optimally.
• It's important to avoid a situation where the whole project is delayed
because a critical task is unfinished.
• Project activities should normally last at least a week. Finer
subdivision means that a disproportionate amount of time must be
spent on estimating and chart revision.
• It is also useful to set a maximum amount of time for any activity of
about 8 to 10 weeks.
• If it takes longer than this, it should be subdivided for project
planning and scheduling.
• When you are estimating schedules, you should not assume that
every stage of the project will be problem free.
• People working on a project may fall ill or may leave, hardware may
break down, and essential support software or hardware may be
delivered late.
• If the project is new and technically advanced, certain parts of it may

turn out to be more difficult and take longer than originally
anticipated.
• As well as calendar time, you also have to estimate the resources
needed to complete each task.
• The principal resource is the human effort required.
• Other resources may be the disk space required on a server, the time
required on specialised hardware such as a simulator, and the travel
budget required for project staff.
• A good rule of thumb is to estimate as if nothing will go wrong, then
increase your estimate to cover anticipated problems.
• Project schedules are usually represented as a set of charts showing
the work breakdown, activities dependencies and staff allocations
• Some Terminologies:
• Ac1vity: Part of a project that takes place over time (also known as a task).
• Event: The end of a group of activities, e.g., agreement by all parties on the
budget and plan
• Dependency: An activity that cannot begin until some event is reached
• Resource: Staff time, equipment, or other limited resources required by
an activity.
• Bar charts and activity networks
• They are graphical notations that are used to illustrate the project
schedule.
• Bar charts show who is responsible for each activity and when the
activity is scheduled to begin and end.
• Activity networks show the dependencies between the different
activities making up a project.
• Activity networks: Task durations and dependencies and activities
will be given.
• Process involved:
• Refer this link for videos: CPM-Video1, CPM-Video2

• Activity networks: Eg:
Immediate Estimated
Activity Predecessor Completion Time (Days)
A None 90
B A 15
C B 5
D G 20
E D 21
F A 25
G C,F 14
H D 28
I A 30
J D,I 45
• From the activity description chart, we can determine immediate
predecessors for each activity.
Activity A is an immediate predecessor of

A B activity B, because it must be competed just
prior to the commencement of B.
• Management gets to know:
• The earliest and latest start times for each activity which will not alter the
earliest completion time of the project.
• The earliest finish times for each activity which will not alter this date.
• Activities with rigid schedule and activities that have slack in their schedules.
• Project Scheduling: Activity networks: Eg:
• Earliest Start Time / Earliest Finish Time
• Make a forward pass through the network as follows:
• Evaluate all the activities which have no immediate predecessors.

• The earliest start for such an activity is zero ES = 0.
• The earliest finish is the activity duration EF = Activity duration.
• Evaluate the ES of all the nodes for which EF of all the immediate predecessor
has been determined.
• ES = Max EF of all its immediate predecessors.
• EF = ES + Activity duration.
• Repeat this process until all nodes have been evaluated

• EF of the finish node is the earliest finish time of the project.
• Earliest Start / Earliest Finish – Forward Pass
90,105 105,110 170
149,170
B C E
B C E
15 5 21
110,124
0,90 90,115 115,129 129,149 177
149,177
A F G D H 194
A F G D H
90 25 14 20 28
EARLIEST FINISH
120,165
90,120 194
149,194
I J
I J
30 45
• Latest start time / Latest finish time: Backward Pass
• Make a backward pass through the network as follows:
• Evaluate all the activities that immediately precede the finish node.
• The latest finish for such an activity is LF = minimal project completion time.
• The latest start for such an activity is LS = LF - activity duration.
• Evaluate the LF of all the nodes for which LS of all the immediate successors
has been determined.
• LF = Min LS of all its immediate successors.
• LS = LF - Activity duration.
• Repeat this process backward until all nodes have been evaluated.
• Latest start time / Latest finish time: Backward Pass
• Slack Times
• Activity start time and completion time may be delayed by planned
reasons as well as by unforeseen reasons.
• Some of these delays may affect the overall completion date.
• To learn about the effects of these delays, we calculate the slack
time, and form the critical path.
• Slack Times
• Slack time is the amount of time an activity can be delayed without
delaying the project completion date, assuming no other delays are
taking place in the project.
• Slack Time = LS - ES = LF - EF
• Critical Path
• The critical path is a set of activities that have no slack,
connecting the START node with the FINISH node.
• The critical activities (activities with 0 slack) form

at least one critical path in the network. A critical path is the longest
path in the network.
• The sum of the completion times for the activities
on the critical path is the minimal completion time
of the project.
• Critical Path Activity LS - ES Slack
A 0 -0 0
B 95 - 90 5
C 110 - 105 5
D 119 - 119 0 Critical activities
E 173 - 149 24
must be rigidly
F 90 - 90 0
G 115 - 115 0 scheduled
H 166 - 149 17
I 119 - 90 29
J 149 - 149 0
• Critical Path
• Risk management:
• Risk management is increasingly seen as one of the main jobs of

project managers.
• It involves anticipating risks that might affect the project schedule or

the quality of the software being developed and taking action to
avoid these risks.
• The results of the risk analysis should be documented in the project

plan along with an analysis of the consequences of a risk occurring.
• Effective risk management makes it easier to cope with problems and

to ensure that these do not lead to unacceptable budget or schedule
slippage.
• There are, therefore, three related categories of risk:
• Project Risks
• Product Risks
• Business Risks
• Project Risks
• It affects the project schedule or resources
• Eg: Experienced designer leaving the organization
• Product Risks
• It affect the quality or performance of the software being developed.
• Eg.:- the failure of a purchased component to perform as expected.
• Business Risks
• They are risks that affect the organisation developing or procuring
the software.
• For example, a competitor introducing a new product is a business
risk.
• These risk types overlap. If an experienced programmer leaves a
project, this can be a project risk because the delivery of the system
may be delayed.
• It can also be a product risk because a replacement may not be as
experienced and so may make programming errors.
• Finally, it can be a business risk because the prograrmmer’s
experience is not available for bidding for future business.
• The risks that may affect a project depend on the project and the
organisational environment where the software is being developed.
• Identify type of risks for below mentioned & Justify:
• Staff turnover
• Management change
• Hardware unavailability
• Requirements change
• Specification delays
• Size underestimate
• CASE tool underperformance
• Technology Change
• Product competition
• Risk management Process:
• 1. Risk identification Possible project, product and business risks are
identified.
• 2. Risk analysis The likelihood and consequences of these risks are
assessed.
• 3. Risk planning Plans to address the risk either by avoiding it or
minimising its effects on the project are drawn up.
• 4. Risk monitoring The risk is constantly assessed and plans for risk
mitigation are revised as more information about the risk becomes
available.
• The risk management process, like all other project planning, is an

iterative process which continues throughout the project.
• Once an initial set of plans are drawn up, the situation is monitored.
• As more information about the risks becomes available, the risks

have to be reanalysed and new priorities established.
• The risk avoidance and contingency plans may be modified as new

risk information emerges.
• Risk management Process: Risk Identification
• Risk identification may be carried out as a team process using a
brainstorming approach or may simply be based on experience.
• To help the process, a checklist of different types of risk may be used.
• There are at least six types of risk that can arise:
• Technology risks, People risks, Organisational risks, Tools risks,

Requirements risk, Estimation risks
• 1. Technology risks Risks that derive from the software or hardware technologies
that are used to develop the system.
• 2. People risks Risks that are associated with the people in the development
team.
• 3. Organisational risks Risks that derive from the organisational environment
where the software is being developed.
• 4. Tools risks Risks that derive from the CASE tools and other support software
used to develop the system.
• 5. Requirements risks Risks that derive from changes to the customer
requirements and the process of managing the requirements change.
• 6. Estimation risks Risks that derive from the management estimates of the
system characteristics and the resources required to build the system.
• Risk management Process: Risk analysis
• During the risk analysis process, you have to consider each identified
risk and make a judgement about the probability and the seriousness
of it.
• There is no easy way to do this-you must rely on your own judgement

and experience, which is why experienced project managers are
generally the best people to help with risk management.
• These risk estimates should not generally be precise numeric
assessments but should be based around a number of bands:
• The probability of the risk might be assessed as very low «10%), low
(10-25%), moderate (25-50%), high (51-75%) or very high (>75%).
• The effects of the risk might be assessed as catastrophic, serious,

tolerable or insignificant.
• Risk management Process: Risk Management
• 1. Avoidance strategies Following these strategies means that the
probability that the risk will arise will be reduced.
• An example of a risk avoidance strategy is the strategy for dealing
with defective components.
• Minimisation strategies Following these strategies means that the
impact of the risk will be reduced.
• An example of a risk minimisation strategy is that for staff illness
• Risk management Process: Risk Management
• Risk management Process: Risk monitoring
Software Requirements
Software Requirements:
• This are the descriptions of the services provided by the system and
its operational constraints.
• These requirements reflect the needs of customers for a system that

helps solve some problem such as controlling a device, placing an
order or finding information.
• The process of finding out, analysing, documenting and checking

these services and constraints is called requirements engineering
(RE).
• The term requirement is not used in the software industry in a
consistent way.
• In some cases, a requirement is simply a high-level, abstract

statement of a service that the system should provide or a constraint
on the system.
• At the other extreme, it is a detailed, formal definition of a system

function.
• If a company wishes to let a contract for a large software development
project, it must define its needs in a sufficiently abstract way that a
solution is not predefined.
• The requirements must be written so that several contractors can bid
for the contract, offering, perhaps, different ways of meeting the
client organisation's needs.
• Once a contract has been awarded, the contractor must write a
system definition for the client in more detail so that the client
understands and can validate what the software will do.
• Both of these documents may be called the requirements document
for the system, then what distinguishes them?
• User requirements and system requirements may be defined as
follows:
• 1. User requirements are statements, in a natural language plus
diagrams, of what services the system is expected to provide and the
constraints under which it must operate.
• 2. System requirements set out the system's functions, services and

operational constraints in detail. The system requirements document
(sometimes called a functional specification) should be precise. It
should define exactly what is to be implemented. It may be part of
the contract between the system buyer and the software developers.
• User requirement definition:
• The system LIBSYS shall keep track of all data required by copyright
licensing agencies in the UK and elsewhere.
• System requirements specification
• 1.1 On making a request for a document from LIBSYS, the requestor
shall be presented with a form that records details of tile user and the
request made.
• 1.2 LIBSYS request forms shall be stored on the system for five years
from the date of the request.
• 1.3 All LIBSYS request forms must be indexed by user, by the name of
the material requested and by the supplier of the request.
• System requirements specification
• 1.4 LIBSYS shall maintain a log elf all requests that have been made to
the system.
• Functional and non-functional requirements:
• I. Functional requirements
• These are statements of services the system should provide, how the
system should! react to particular inputs and how the system should
behave in particular situations.
• In some cases, the functional requirements may also explicitly state

what the system should not do.
• Functional and non-functional requirements: Example
• 2 Non-functional requirements
• These are constraints on the services or functions offered by the
system.
• They include timing constraints, constraints on the development

process and standards. Non-functional requirements often apply to
the system as a whole.
• They do not usually just apply to individual system features or

services.
• Functional and non-functional requirements: Example
• 2 Non-functional requirements
• These are constraints on the services or functions offered by the
system.
• They include timing constraints, constraints on the development

process and standards. Non-functional requirements often apply to
the system as a whole.
• They do not usually just apply to individual system features or

services.
• System requirements
• System requirements are expanded versions of the user requirements
that are used by software engineers as the starting point for the
system design.
• They add detail and explain how the user requirements should be
provided by the system.
• They used as part of the contract for the implementation of the

system and should therefore be a complete and consistent
specification of the whole system.
• System requirements
• Ideally, the system requirements should simply describe the external
behaviour of the system and its operational constraints.
• Natural language is often used to write system requirements
specifications as well as user requirements.
• They should not be concerned with how the system should be
designed or implemented.
• However, at the level of detail required to completely specify a

complex software system, it is impossible, in practice, to exclude all
design information

It601 Se Material Till Class Test PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

It601 Se Material Till Class Test PDF

Uploaded by

Copyright:

Available Formats

SE Material Till Class Test

Prof. Daiwat Vyas

develop a quality software project through effective team-building, planning, scheduling

• Engineering is all about developing products, using well-defined,

• Engineering is the application of well-understood scientific

• Software is more than just a program code.

• Software can be:

• Custom:- Developed for a specific customer according to customers

• Software engineering is associated with development of software

• When a software project succeeds? When it meets the need of

• Analogy to understand importance of SE in software

• Software development and software engineering are interrelated

• Software engineering means applying engineering principles to software

• Software engineers begin with a thorough study of requirements.

• Software development is the process of developing software

• Data structures that enable the programs to adequately manipulate

• Documents that describe the operation and use of the programs

• Software doesn't wear out

• Software is not susceptible to environmental maladies

• Not used, not up to date, not complete, not focused on quality,

• Adding people to a late software project makes it more late

• "If I decide to outsource the software project to a third party, I can

• Software projects need to be controlled and managed

• "A general statement of objectives is sufficient to begin writing

• Ambiguous statement of objectives spells disaster

• "Project requirements continually change, but change can be easily

• Impact of change depends on where and when it occurs in the

• 60% to 80% of all effort expended on software occurs after it is

• "Until I get the program running, I have no way of assessing its

• "The only deliverable work product for a successful project is the

• Software, documentation, test drivers, test results

• "Software engineering will make us create voluminous and

• Creates quality, not documents; quality reduces rework and

• The bedrock that supports software engineering is a quality focus.

• The foundation for software engineering is the process layer.

• A set of activities, methods, practices, and transformations that

• (IEEE) A sequence of steps performed for a given purpose

• It establish the context in which technical methods are applied, work

• Methods encompass a broad array of tasks that include requirements

• Software engineering methods rely on a set of basic principles that

• Software engineering tools provide automated or semi-automated

• When tools are integrated so that information created by one tool

• It creates a software engineering environment

• Eg.: ArgoUML, Rational Rose

• A number of task sets—each a collection of software engineering

• Involves communication among the customer and other stake

• Construction (Code, Test)

• Software requirements management

• This means that SE projects must produce additional deliverables

• This strategy is often referred to as a process model or a software

• in order to optimise: • project risk [low] (see later) • profit [high] •

• resources needed(people, money, equipment, etc)

• It is impossible to measure rate of progress except with reference to

• part of a larger system (or business), work begins by establishing

• all system elements and then allocating some subset of these

• System engineering and analysis encompass-

• requirements gathering at the system level with a small amount of

• understand the information domain for the software, as well as

• a multistep process that focuses on four distinct attributes of a

• The code generation step performs this task. If design is performed in

• It is often difficult for the customer to state all requirements

• The linear sequential model requires this and has difficulty

• The customer must have patience.