Software Engineering chapter-1 IOE, TU

1. Software Process &
Requirement
Chapter 1

2. Software Crisis
The software crisis was seen from 1960 to 1980s.
During this time, many software industry unsuccessfully attempted to build larger
system software.
As the era was not completely ready for the larger system software and huge
investment in the same time resulted in software crisis.
The term “Software Crisis” is not actual scarcity of software
 it is the situation where number of successful software is negligible compared to
number of unsuccessful software.

3. Software Crisis
During those days, the success of any software was measured in terms of the
cost and scheduled time.
Hence, software crisis is defined as the inability to develop software on time,
on budget and within requirements.
Though, cost and time being important factors, some other factors are also
responsible towards software failure.
Increasing Demand, Low Expectation, Lack of problem understanding are
other factors causing the crisis.

4. Factors enhancing Software Crisis
1. Increasing demand:
The technological demand always seem to be increasing.
System has to be built and delivered more quickly than before, and even complex
systems are also required.
Such increase in the demand leads to evolution of new requirements for the software.
In such case, existing and used software engineering methods cannot cope with the
changes.
So, this increasing demand affects the success rate of any software causing software
crisis.

5. 2. Low expectation:
The user group wants to software to be delivered fast and in cheap cost.
Taking these aspects into account, the software developers have low expectations
for the software they undertake in that time constraints and cost.
Under such circumstances, the developers skip the correct use of software methods
which increase the chances for software failure.

6. 3. Lack of problem understanding:
After the industrial revolution, the world moved towards automation.
And, for automation system software are required.
But the people who wanted system software had not much idea about what they
want for their problem
i.e. they were not clear regarding their requirements.
At the same time, there were not many experts who could elaborate the problem
into understandable form.

7. Software Engineering
The term “Software Engineering” was first proposed in 1967 at a NATO conference held to
discuss what was then called “software crisis”.
It became clear that individual approaches to program development did not scale up to large
and complex software systems.
These approaches were unreliable, cost more than expected and were delivered late.
So, NATO defined software engineering as “The establishment and use of sound
engineering principles in order to obtain economically software that is reliable and works
efficiently on real machines.”

8. According to IEEE, “Software engineering is the application of a systematic,
disciplined, quantifiable approach to the development, operation, and maintenance
of software.”
Basically, software Engineering is a systematic approach to the analysis, design,
implementation and maintenance of software.
Software Engineering is an engineering discipline that is concerned with all aspects
of software production from the early stages of system specification through to
maintain the system after it has gone into use.
Here, two aspects of software were defined: Software Characteristics & Software
Process Activities

9. Software Characteristics
Maintainability Software should be written in such a way so that is can evolve
to meet the changing needs of customers. This is a critical
attribute because software change is inevitable requirement of
a changing business environment.
Dependability &
Security
Software dependability include a range of characteristics such
as reliability, security and safety. A software must be available
at any time and should not cause physical or economic
damage in event of system failure.

10. Efficiency Software should not make wasteful use of system resource
such as memory and processor cycles. Efficiency includes
memory utilization, process management, responsiveness,
etc.
Acceptability Software must be acceptable to the types of users for which
it is designed. It must be understandable, usable and
compatible with other system that they use.

11. Software Process Activities
Software Engineering has defined 4 process for the software development.
1. Software Specification
2. Software Design & Implementation
3. Software Validation
4. Software Evolution

12. Software Specification
also known as requirement engineering
process of understanding and defining what services are required for the system,
identifying constraints on system’s operation and development
it may include a set of functionalities (use cases) that describe user interactions that
the software must provide to the user for perfect interaction.
Its outcome is the Software Requirement Specification (SRS) document
It describes what the software will do and how it will be expected to perform.
It also describes the functionality the product needs to fulfill and stakeholders need

13. Software requirements specification establishes the basis for an agreement between
customers and contractors or suppliers on how the software product should
function (in a market-driven project, these roles may be played by the marketing and
development divisions).
 Software requirements specification is a rigorous assessment of requirements
before the more specific system design stages, and its goal is to reduce later
redesign.
It should also provide a realistic basis for estimating product costs, risks, and
schedules. Used appropriately, software requirements specifications can help prevent
software project failure.

14. Software Design & Implementation
process of converting a system specification and user requirements into an
executable system
Software design is description of structure of software to be implemented, data
models, structure used by system.
no immediate implementation but helps the programmers in coding and
maintenance
add formality and detail as they develop their design with constant backtracking to
correct earlier design
First step in SDLC where problem domain is mapped to solution domain

15. • the design and implementation considers following four areas
1. Architectural design: identify all structure of system, principal component,
relationship and distribution.
2. Interface design: the interface of components must be unambiguous so that the
integration of components can be designed concurrently
3. Component design: operation of component, its functionality and list of reusable
components must be explicitly defined
4. Database design: design of system data structure and how they are represented must
by explicitly defined

16. • Outcome of software design
• Correctness: Software design should be correct as per requirement.
• Completeness: The design should have all components like data structures, modules,
and external interfaces, etc.
• Efficiency: Resources should be used efficiently by the program.
• Flexibility: Able to modify on changing needs.
• Consistency: There should not be any inconsistency in the design.
• Maintainability: The design should be so simple so that it can be easily maintainable
by other designers.

17. Software Validation
• Software Validation is a process of evaluating software product
• it shows how system conforms to its specification and expectation of system user
• It is basically, performed with the intent to check that whether the developed
software is built as per pre-decided software requirement specifications (SRS)
• more than half of the development cost is allocated for this process
• involves checking and reviewing of the system
• validation process involves component, system and acceptance test

18. 1.Component test: the individual
component is tested with the simulated
data by the developer
2.System test: the components are
integrated and tested as black box (input
is given to system to observe output)
3.Acceptance test: system is tested with
the input data provided by user to verify
whether the system works correctly or
not

19. Software Evolution
It is the process of developing a software product using software engineering
principles and methods.
This includes the initial development of software and its maintenance and updates,
till desired software product is developed, which satisfies the expected requirements.
the tested software when implemented in real environment are prone to errors
since the requirements are changing, the changes are worked and designed to
support the errors as part of the maintenance
the software is continually changes over its lifetime in response to changing
requirement and customer needs

20. Even after the user has desired
software in hand, the advancing
technology and the changing
requirements force the software
product to change accordingly.
Re-creating software from scratch and
to go one-on-one with requirement is
not feasible.
The only feasible and economical
solution is to update the existing
software so that it matches the latest
requirements.

21. Functional Requirement
statements of services the system should provide
describes what the system should do
these requirements depend on the type of software being developed, expected
users
define specific facilities to be provided by the system
includes how the system should react to particular inputs
and how the system should behave in particular situations
the functional requirements should be unambiguous, complete and consistent

22. Non-functional Requirements
requirements that are not directly concerned with the specific services to be
delivered by the system
defines system properties and constraints
affects the overall architecture of the system
a non-functional requirement may generate a number of functional
requirements
non-functional requirements may be more critical than the functional
requirement (i.e. if these are not meet, system is a failure)
such requirement arise through user needs and policies of user group

23. User Requirements
User requirements, often referred to as user needs,
describe what the user does with the system, such as what activities that users must
be able to perform.
User requirements are generally documented in a User Requirements Document
(URD) using narrative text.
User requirements are generally signed off by the user and used as the primary
input for creating system requirements.

24. System Requirements
more detailed specifications of system’s functions
defines what is exactly implemented in the system
may be part of contract between system users and developers
may include object models, data flow models.
Also includes the hardware and software required for the development

25. Requirement Engineering Process

26. it is the process of establishing the services that the customer requires from a
system and the constraints under which it operates and is developed
it includes four high-level activities
these activities focus on assessing if the system is useful to business
it discovers the requirements, converts into standard form and checks the validity of
the requirements
its four high-level activities are mentioned below

27. Feasibility Study
this activity accesses if the system is useful or not
estimates of whether identified user needs may be satisfied
is done using current software and hardware
it is cost effective
its report decides whether project should forward or be rejected

28. Requirement Elicitation & Analysis
process of deriving the system requirement through observation of existing system
it emphasizes on discovering the requirements
it includes discussion with experts
helps to understand the system to be built
may involve the development of one or more system models or prototypes

29. Requirement Specification
• A Requirement Specification is a collection of the set of all requirements that are to
be imposed on the design and verification of the product
• transformation of gathered information during elicitation activity
• The specification also contains other related information necessary for the design,
verification, and maintenance of the product.
• The Requirement Specification should state what in terms of features, functions,
performance, constraints, and quality, written in terms of what the product must do
or qualities it must have.

30. Requirement Validation
• It’s a process of ensuring the specified requirements meet the customer needs.
• activity for checking realism, consistent and completeness
• Concerned with discovering the errors in the gathered requirements
• provides a refined document about the specification of the system design

31. Requirement Elicitation & Analysis

32. Requirement Discovery
• The requirements for the system to be developed is worked out.
• The existing components are discovered.
• The requirements are discovered as per the reusable component.
• The requirements are explored thoroughly to detail out the minute hidden
meanings.

33. Requirements Classification & Organization
• The discovered requirements are classified under different heading and subjects.
• These headings and subjects refer to the component and functionality to be
developed and are organized in some order.

34. Requirements Prioritization & Negotiation
• The classified and organized requirements are given priority numbers as per the
system requirements.
• The immediate components to be developed are given high priority and so on.
• While the requirements for the reusable component are negotiated for the
betterment of the system development.

35. Software Development Models
1. Waterfall Model
2. Incremental Model
3. Prototyping Model
4. Spiral Model
5. Rapid Application Development Model
6. Agile Principles

36. Waterfall Model
 Waterfall model is one of the earliest
development model.
 It is also known as linear sequential model
because of the sequential phases.
 The sequential phases is what makes this
model simple systematic in nature.
 The development process is represented
by sequence of steps like the waterfall.
 Each phases should be completed before
moving into next phase.

37. Characteristics
It is also referred to as a linear-sequential life cycle model.
It is very simple to understand and use.
In a waterfall model, each phase must be completed before the next phase can begin
and there is no overlapping in the phases.
Here the requirements tend to remain same i.e. no place for requirement change
This is applicable for large projects and where requirements are unlikely to change.

38. Advantages
1. Simple and easy to understand and use
2. Easy to manage due to the rigidity of the model.
3. Each phase has specific deliverables and a review process.
4. Phases are processed and completed one at a time.
5. Works well for smaller projects where requirements are very well understood.
6. Clearly defined stages.
7. Well understood milestones.
8. Easy to arrange tasks.
9. Process and results are well documented.

39. Disadvantages
1. No working software is produced until late during the life cycle.
2. High amounts of risk and uncertainty, poor model for long and ongoing projects.
3. Not a good model for complex and object-oriented projects.
4. Not suitable for the projects where requirements are at a moderate to high risk of
changing. So, risk and uncertainty is high with this process model.
5. It is difficult to measure progress within stages.
6. Cannot accommodate changing requirements.
7. Adjusting scope during the life cycle can end a project.
8. Integration is done as a "big-bang. at the very end, which doesn't allow identifying
any technological or business bottleneck or challenges early.

40. Prototyping Model

41. Characteristics
In this model, the developer and client interact to establish the requirements of the
software.
It defines the broad set of objectives.
The quick design stresses the client view of the software.
It includes the components from other similar projects that can be re-used.
The input and output and visible elements are quickly designed.
The process continues in an iterative manner until all the users’ requirements are
met.

42. Advantages
1. The objectives and requirements of the software is well established.
2. Suitable for those projects where the clients has no clear idea about his
requirements.
3. An initial working model is delivered quickly.
4. The client can provide its input during development of the prototype.
5. The prototype serves as an aid for the development of the final product.
6. We can find missing functionality easily.
7. There is scope of refinement, it means new requirements can be easily
accommodated.

43. Disadvantages
1. The quality of the software development is compromised in the rush to present a
working model.
2. Customers sometimes demand the actual product to be delivered soon after seeing
an early prototype.
3. It becomes difficult for the developers to convince user why the prototypes are
discarded.
4. There may be too much variation in requirements.
5. It has poor documentation because of continuously changing customer
requirements.

44. Spiral Model

45. Characteristics
 This model consists of a number of activities called task regions.
 The task regions are communication, planning, risk analysis, design, construction &
release and evaluation.
 The process is presented as a spiral, each loop in the spiral represents a process phase.
 No distinct phases for development.
 It emphasizes at quick development of the software, which is releases in increments.
 It is used when experimenting new technology, trying out new skill and when customers
don’t have a clear requirements.
 This model has capability to handle risks.

46. Advantages
1. This model is more flexible with large real-life project development.
2. Prototyping can be applied at any level in the evaluation process.
3. This helps to reduce the technical risk and the cost.
4. Suitable for application that can use an Object Oriented approach.
5. The quality of the software is assured though the risk analysis.
6. In this model, we can easily change requirements at later phases and can be
incorporated accurately. Also, additional Functionality can be added at a later date.

47. Disadvantages
1. It can cause problems in negotiating a development contract with the client.
2. Difficulty in time management. As the number of phases is unknown at the start
of the project, so time estimation is very difficult.
3. Spiral may go on indefinitely.
4. May be hard to define objective, verifiable milestones.
5. Large numbers of intermediate stages require excessive documentation.
6. Too much dependable on Risk Analysis and requires highly specific expertise.

48. Incremental Model

49. Characteristics
It is combination of waterfall and iterative approach of prototyping model.
The software is developed and delivered in small increments i.e. a component at a
time.
The prototyping model is applied to each process flow of each increments.
The delivered first increment is the core product.
The increments are constantly evaluated and reviewed by the clients.
Bases on the reviews and evaluation for the core product, the developers prepare
plan for the next increment.
The phases are interleaved i.e. the activities are concurrently taking place.
New features and functionality are also taken into consideration.

50. Advantages
1. It guarantees early delivery of the final products.
2. It requires less human resources especially for the first new increments.
3. It involves the working of all the development teams so unavailability of any team
member doesn’t affect delay of the project.
4. It deals with changing requirements from the user.
5. Easier to test and debug during a smaller iteration.
6. Easier to manage risk because risky pieces are identified and handled during its
iteration.

51. Disadvantages
1. Each phase of an iteration is rigid and do not overlap each other.
2. Problems may arise pertaining to system architecture because not all requirements
are gathered up front for the entire software life cycle.
3. Software Quality is rushes for the early development of the core product.
4. Since the process are interleaved, the process activities are not visible.
5. The system architecture can be corrupted due to continuous changes.

52. Rapid Application Development

53. Steps involved in RAD
Business
Modeling
On basis of the flow of information and distribution between
various business channels, the product is designed
Data Modeling The information collected from business modeling is refined into
a set of data objects that are significant for the business
Process
Modeling
The data object that is declared in the data modeling phase is
transformed to achieve the information flow necessary to
implement a business function

54. Application Generation Automated tools are used for the construction of the
software, to convert process and data models into
prototypes
Testing and Turnover As prototypes are individually tested during every iteration,
the overall testing time is reduced in RAD.

55. Characteristics
• RAD follows a cycle of rapid prototyping and
• Quick feedback from the end user to ensure that development is quick, and that
users are constantly updated on the progress of the software
• The system to be developed is divided up into a number of components or time-
boxes that are developed separately
• It follows the pareto principle i.e. the 80/20, around 80 per cent of a systems’
functionality can be delivered with around 20 per cent of the effort needed to
complete 100 per cent of the requirements.

56. Advantages
• Flexible and adaptable to changes
• Quick iterations that reduce development time and speed up delivery
• It is useful when you have to reduce the overall project risk
• It is easier to transfer deliverables as scripts, high-level abstractions and intermediate codes are
used.
• Due to code generators and code reuse, there is reduction of manual coding
• Increased customer satisfaction due to high level collaboration and coordination between
stakeholders (developers, clients and end users)
• Each phase in RAD delivers highest priority functionality to client

57. Disadvantages
• It cant be used for smaller projects, only suitable for projects having small development time
• When technical risk is high, it is not suitable
• Need user requirements throughout the life cycle of the product
• Reduced features due to time boxing, where features are pushed to a later version to finish a
release in short period
• Only systems which can be modularized can be developed using this model of development.
• Progress and problems accustomed are hard to track as such there is no documentation to
demonstrate what has been done
• Requires highly skilled designers or developers

58. Agile Manifesto
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

59. Agile Principles
1. Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes
harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.

60. 6. The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and
users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
11. The best architectures, requirements, and designs emerge from self-organizing
teams.