Aaa

5. CO-1. Define the requirements for the development of
application.
CO-2. Identify the Concepts of Agile methodology.
CO-3. Compare lifecycle models of software
development.
CO-4. Choose appropriate software engineering
methodology
CO-5. Analyze knowledge of project management
CO-6. Examine software testing problems by
designing test models, criteria, strategies and methods.

6. Software Engineering:
• Software : Software is defined as,
1. Instructions : Programs that when executed provide desired function, features,
and performance
2. Data structures : Enable the programs to adequately manipulate information
3. Documents: Descriptive information in both hard copy and virtual forms that
describes the operation and use of the programs.
• Engineering: It is all about developing products, using well-defined, scientific
principles and methods.
• Software is engineered, not manufactured.
• Software Development: It is process of designing, programming,
documenting, testing, and bug fixing.

7. SOFTWARE
Programs
Documentation
Operating
Procedures

8. • Software Does not wear out, it deteriorates.
Below curves of failure for hardware and software with time, shows
software is not susceptible to the environmental maladies that can cause
hardware to wear out.
Fig 1: Failure curve for
hardware
Fig 2: Failure curve for software

9. Essential attributes of good software:

10. Software Application Domains:
Seven Broad Categories of software are challenges for software engineers
1. System Software
2. Application Software
3. Engineering/scientific
software
4. Embedded software
5. Product-line software
6. Web applications (aka
WebApps)
7. Artificial intelligence software
What characteristics differentiates WebApps from other
software?
• Network intensiveness
• Concurrency
• Unpredictable load
• Performance
• Availability
• Data driven
• Content sensitive
• Continuous evolution
• Security
• Aesthetics

11. Software Engineering -A Layered Technology:
IEEE has developed a more comprehensive definition as :
1) Software engineering is the application of a systematic, disciplined,
quantifiable
approach to the development, operation, and maintenance of software.
2) The study approaches as in (1)
Software Engineering is a layered technology. Software Engineering
encompasses a
Process, Methods for managing and engineering software and tools.

12. Professional Software Development:
Difference between professional and amateur software development.
The professionally developed software system usually consists of a number of
separate programs and configuration files that are used to set up these programs. It
may include system documentation, which describes the structure of the system;
user documentation, which explains how to use the system, and websites for users
to download recent product information.
Software engineers are concerned with developing software products (i.e., software
which can be sold to a customer). There are two kinds of software products:
1. Generic products: These are stand-alone systems that are produced by a
development organization and sold on the open market to any customer who is
able to buy them. Examples of this type of product include software for PCs
such as databases, word processors, drawing packages, and project-
management tools.
2. Customized (or bespoke) products: These are systems that are commissioned
by a particular customer. A software contractor develops the software especially
for that customer. Examples are electronic devices, systems written to support a
particular business process, and air traffic control systems.

13. The Software Engineering Practice:
I. Understand the Problem
(communication and analysis)
• Who are the stakeholders?
• What functions and features are required to
solve the problem?
• Is it possible to create smaller problems that
are easier to understand?
• Can a graphic analysis model be created?
II. Plan the Solution (software design)
• Have you seen similar problems before?
• Has a similar problem been solved?
• Can readily solvable sub problems be
defined?
• Can a design model be created?
III. Carry Out the Plan (code generation)
• Does solution confirm to the plan?
• Is each solution component provably
correct?
IV. Examine the Result (testing and quality
assurance)
• Is it possible to test each component part of
the solution?
• Does the solution produce results that
conform to the data, functions, and features
required?

14. Software Engineering Ethics and Principles:
Some common ethics are:
• Confidentiality
• Competence
• Intellectual property rights
• Computer misuse
General Principles:
David Hooker has Proposed seven principles that focus on software Engineering
practice.
• The First Principle: The Reason It All Exists
A software system exists for one reason: to provide value to its users.
• The Second Principle: KISS (Keep It Simple, Stupid!)
Software design is not a haphazard process. There are many factors to consider in
any design effort. All design should be as simple as possible, but no simpler.
• The Third Principle: Maintain the Vision
A clear vision is essential to the success of a software project. Without one, a
project almost unfailingly ends up being “of two [or more] minds” about itself.

15. • The Fourth Principle: What You Produce, Others Will Consume
Always specify, design, and implement knowing someone else will have to
understand what you are doing.
• The Fifth Principle: Be Open to the Future
A system with a long lifetime has more value. Never design yourself into a
corner. Before beginning a software project, be sure the software has a
business purpose and that users
perceive value in it.
• The Sixth Principle: Plan Ahead for Reuse
Reuse saves time and effort. Planning ahead for reuse reduces the cost and
increases the value of both the reusable components and the systems into which
they are incorporated.
• The Seventh principle: Think!
Placing clear, complete thought before action almost always produces better
results. When you think about something, you are more likely to do it right.

16. CASE STUDIES

17. CASE STUDIES
Embedded
system
Information system
Sensor-based data
collection system
1. An embedded system is a system where the software controls a hardware device and
is embedded in that device.. The example we will see here is a software system to
control a medical device.
2. An information system is a system whose primary purpose is to manage
and provide access to a database of information. The examplewe will see here is a medical
records system.
3. A sensor-based data collection system is a system whose primary purpose
is to collect data from a set of sensors and process that data in some way. The example we
will see here is wilderness weather station.

18. Case Study 1:An insulin pump control system
Fig:
Insulin
pump hardware
An insulin pump is a medical system that simulates the operation of the pancreas (an internal
organ). The software controlling this system is an embedded system, which collects
information from a sensor and controls a pump that delivers a controlled dose of insulin to a
user.
Figure shows the hardware components and organization of the insulin pump.

19. There are two essential high-level requirements that this system must meet:
1. The system shall be available to deliver insulin when required.
2. The system shall perform reliably and deliver the correct amount of insulin to
counteract the current level of blood sugar.
Figure is a UML activity model that illustrates how the software transforms an input
blood sugar level to a sequence of commands that drive the insulin pump.
Fig: Activity model of the insulin pump

20. Case Study 2: A patient information system
for mental health care
• A patient information system to support mental health care is a medical information
system that maintains information about patients suffering from mental health problems
and the treatments that they have received.
• The MHC-PMS (Mental Health Care-Patient Management System) is an information system that is
intended for use in clinics. It makes use of a centralized database of patient information but has also
been designed to run on a PC, so that it may be accessed and used from sites that do not have secure
network connectivity. When the local systems have secure network access, they use patient information
in the database but they can download and use local copies of patient records when they are
disconnected
The MHC-PMS has two overall goals:
1. To generate management information that allows health service managers to assess performance
against local and government targets.
2. To provide medical staff with timely information to support the treatment of patients.
Fig: The organization of
the MHC-PMS

21. Case Study 3: A wilderness weather station
Fig: The weather station’s environment
The systems in Figure are:
1. The weather station system responsible for collecting weather data, carrying out some
initial data processing, and transmitting it to the data management system.
2. The data management and archiving system collects the data from all of the wilderness
weather stations, carries out data processing and analysis, and archives the data in a form
that can be retrieved by other systems, such as weather forecasting systems.
3. The station maintenance system can communicate by satellite with all wilderness
weather stations to monitor the health of these systems and provide reports of problems.
In Figure the UML package symbol is used to indicate that each
system is a collection of components and have identified the
separate systems, using the UML stereotype «system».

22. The station software is therefore not just concerned with data collection. It
must also:
1. Monitor the instruments, power, and communication hardware and report
faults to the management system.
2. Manage the system power, ensuring that batteries are charged whenever
the environmental conditions permit but also that generators are shut down in
potentially damaging weather conditions, such as high wind.
3. Allow for dynamic reconfiguration where parts of the software are
replaced with new versions and where backup instruments are switched into
the system in the event of system failure.
Because weather stations have to be self-contained and unattended, this
means that the software installed is complex, even though the data collection
functionality is fairly simple.

23. The Software Process:
• Process is a collection of activities, actions, and tasks that are
performed when some work product is to be created.
• Activity strives to achieve a broad objective (e.g., communication with
stakeholders) and is applied regardless of the application domain, size of the
project, complexity of the effort, or degree of rigor with which software
engineering is to be applied.
• Action encompasses a set of tasks that produce a major work product (e.g., an
architectural design model).
• Task focuses on a small, but well-defined objective (e.g., conducting a unit test)
that produces a tangible outcome.
• Process framework establishes the foundation for a complete software
engineering process by identifying a small number of framework activities that
are applicable to all software projects, regardless of their size or complexity.
• The process framework encompasses a set of umbrella activities that are
applicable across the entire software process.

25. Generic process framework for software engineering encompasses
five activities:
• Communication
• Planning
• Modeling
• Construction
• Deployment
Umbrella activities are applied throughout a software project and help a software
team manage and control progress, quality, change, and risk. Typical umbrella
activities include:
• Software project tracking
• Risk management
• Software quality assurance
• Technical reviews
• Measurement
• Software configuration management
• Reusability management
• Work product preparation and production

26. The Software Process Models:
A. PRESCRIPTIVE PROCESS MODELS:
Prescriptive process models define a prescribed set of process elements
and a predictable process work flow. “prescriptive” because they prescribe a set of process
elements—framework activities, software engineering actions, tasks, work products, quality
assurance, and change control mechanisms for each project.
1. The Waterfall Model :
• Aka classic life cycle, suggests a systematic, sequential approach to software
development.
• The oldest paradigm for software engineering
• This model is suitable when ever limited number of new development efforts and
when requirements are well defined and reasonably stable.

27. • A variation in the representation of the waterfall model
• As a software team moves down the left side of the V, basic problem requirements are
refined into progressively more detailed and technical representations of the problem and its
solution. Once code has been generated, the team moves up the right side of the V,
essentially performing a series of tests that validate each of the models created as the team
moved down the left side.
• V-model provides a way of visualizing how verification and validation actions are
applied to earlier engineering work.
2. The V Model :
Limitations:
• Real projects rarely
follow the sequential
flow that the model
proposes.
• It is often difficult for
the customer to state all
requirements explicitly.
• The customer must have
patience. A working
version of the
program(s) will not be
available until late in the
project time span.

28. 3. The Incremental Process Model :
• The incremental model
delivers a series of
releases, called increments,
that provide progressively
more functionality for the
customer as each
increment is delivered.
• Combines elements of
linear and parallel process
flows.
• Each linear sequence
produces deliverable
“increments” of the
software.
• The first increment is often
a core product.

29. B. EVOLUTIONARY PROCESS MODELS: (Coping with change)
They are iterative. They are characterized in a manner that enables you to
develop increasingly more complete versions of the software with each iteration.
1. Prototyping Model :
• Prototyping can be used as a stand-alone process model.
• In the cases where 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 a prototyping paradigm may offer the best approach.
• It begins with communication, iteration is planned quickly, and modeling (in the form of a
“quick design”) occurs.
• A quick design focuses on a representation of those aspects of the software that will be
visible to end users and leads to the construction of a prototype.
Limitations:
• Stakeholders see what appears to be a
working version of the software, unaware that
the prototype is held together haphazardly,
unaware that in the rush to get it working you
haven’t considered overall software quality or
long-term maintainability.
• As a software engineer, you often make
implementation compromises in order to get
a prototype working quickly.

30. 2. The Spiral Model :
• The spiral development model is a risk-driven process model generator
that is used to guide multi-stakeholder concurrent engineering of software
intensive systems.
• The two main distinguishing features-
a. cyclic approach for incrementally growing a system’s degree of definition and
implementation while decreasing its degree of risk.
b. anchor point milestones for ensuring stakeholder commitment to feasible and mutually
satisfactory system solutions.
• A spiral model is divided into a set of framework activities defined by the software
engineering team.
• The software team performs activities that are implied by a circuit around the spiral in a
clockwise direction, beginning at the center.
• Risk is considered as each revolution is made.
• Anchor point milestones are a combination of work products and conditions that are
attained along the path of the spiral are noted for each evolutionary pass.
• The first circuit around the spiral might represent a “concept development project”.
• Later, a circuit around the spiral might be used to represent a “product enhancement
project.”
• It is a realistic approach to the development of large-scale system and software.

32. 3. Concurrent Model :
• Sometimes called concurrent engineering, allows a software team to represent
iterative and concurrent elements of any of the process models.
• These models provides a schematic representation of one software engineering activity
within the modeling activity using a concurrent modeling approach. The activity
modeling may be in any one of the states noted at any given time. Similarly, other
activities, actions, or tasks (e.g., communication or construction) can be represented
in an analogous manner.

33. Process activities:
• Four basic process activities:
a. Specification
b. Development
c. Validation
d. evolution
a. Software specification

34. Feasibility Study:
• assess from the
• A. operational,
• B. technical,
• C. economic and
• D. organizational point of view whether the project is viable.
Types of feasibility to be analyzed
Organizational viability: it is related to how much the solution benefits the organization.
It is verified if there will be adherence to the use of the solution by the users due to the
organizational culture and the perception of those involved; whether the solution is
aligned with the organization’s strategic objectives; whether there is understanding and
support from the organization’s top management in relation to the project, etc.
Operational viability: it is related to how much the solution suits the organization; what
are the requirements of the solution; what the customer expects the system to do;
Economic viability: analysis between the development cost and the benefits after the
project is implemented (cost-benefit).
Technical software feasibility: linked to the technical support that the organization will
offer for the development of the project; team or technology restrictions; need to invest
in research before carrying out the project; etc.
Timeline feasibility: crossing between the activities surveyed and the estimated time to
carry them out; definition of project milestones; impact of delays.
Others: legal, cultural, marketing, etc.

35. b. Software design and implementation

36. c. Software validation
d. Software evolution

37. The Rational Unified Process:
• The Rational Unified Process (RUP) is an example of a
Modern process model that has been derived from work on the UML and the
associated Unified Software Development Process
• The RUP recognizes that conventional process models present a single view of the process.
In contrast, the RUP is normally described from three perspectives:
1. A dynamic perspective, which shows the phases of the model over time.
2. A static perspective, which shows the process activities that are enacted.
3. A practice perspective, which suggests good practices to be used during the process
Fig: Phases in the Rational Unified Process