Download Software Engineering Study Martial and more Lecture notes Software Engineering in PDF only on Docsity!
Unit-1 –Introduction to Software and
1. Software Engineering
Software Engineering 1
(1) Software & Software Engineering
Software:
Computer software is the product that software professionals build and then support over the long term.
It encompasses programs that execute within a computer of any size and architecture, content that is
presented as the computer programs execute, and descriptive information in both hard copy and virtual forms that encompass virtually any electronic media.
Characteristics of software :
[1] Software is developed or engineered; it is not manufactured in the classical sense:
Although some similarities exist between software development and hardware manufacturing, but few
activities are fundamentally different.
In both activities, high quality is achieved through good design, but the manufacturing phase for
hardware can introduce quality problems than software.
[2] Software doesn’t “wear out.”
Hardware components suffer from the growing effects of dust, vibration, abuse, temperature extremes,
and many other environmental maladies. Stated simply, the hardware begins to wear out.
Software is not susceptible to the environmental maladies that cause hardware to wear out. In theory,
therefore, the failure rate curve for software should take the form of the “idealized curve”.
When a hardware component wears out, it is replaced by a spare part.
There are no software spare parts.
Every software failure indicates an error in design or in the process through which design was translated
into machine executable code.
Therefore, the software maintenance tasks that accommodate requests for change involve considerably
more complexity than hardware maintenance.
However, the implication is clear—software doesn’t wear out. But it does deteriorate.
Hardware Failure curve Software Failure curve
[3] Although the industry is moving toward component-based construction, most software continues to be custom built.
A software component should be designed and implemented so that it can be reused in many different
programs.
Modern reusable components encapsulate both data and the processing that is applied to the data,
enabling the software engineer to create new applications from reusable parts.
In the hardware world, component reuse is a natural part of the engineering process
Difference between program and software
Program Software
Small in size.
Authors himself is user-soul.
Single developer.
Adopt development.
Lack proper interface.
Large proper documentation.
Software Myths:
Large in size.
Large number.
Team developer.
Systematic development.
Well define interface.
Well documented
Software myths are beliefs about software and the process used to build it.
(1) Management Myths:
Myth 1: We already have a book that’s full of standards and procedures for building software. Won’t that provide my people with everything they need to know? Reality: The book of standards may very well exist, but is it used? Are software practitioners aware of its existence? Does it reflect modern software engineering practice? Is it complete? Is it adaptable? Is it streamlined to improve time-to-delivery while still maintaining a focus on quality? In many cases, the answer to all of these questions is no.
Myth 2: If we get behind schedule, we can add more programmers and catch up. Reality:
Software development is not a mechanistic process like manufacturing. As new people are added, people who were working must spend time educating the newcomers, thereby reducing the amount of time spent on productive development effort. People can be added but only in a planned and well-coordinated manner. Myth 3:
If I decide to outsource the software project to a third party, I can just relax and let that firm build it.
Reality:
If an organization does not understand how to manage and control software projects internally, it will invariably struggle when it outsources software projects.
Myth 4:
Software engineering will make us create voluminous and unnecessary documentation and will invariably slow us down.
Reality:
Software engineering is not about creating documents. It is about creating a quality product. Better quality leads to reduced rework. And reduced rework results in faster delivery times.
Software Engineering :
Software Engineering is the application of a systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software; that is, the application of engineering to software.
A Layered Technology:
A quality Focus :
Figure: Software Engineering Layers
Every organization is rest on its commitment to quality.
Total quality management, Six Sigma, or similar continuous improvement culture and it is this culture
ultimately leads to development of increasingly more effective approaches to software engineering.
The foundation that supports software engineering is a quality focus.
Process:
The software engineering process is the glue that holds the technology layers together and enables
rational and timely development of computer software.
Process defines a framework that must be established for effective delivery of software engineering
technology.
The software process forms the basis for management control of software projects and establishes the
context in which technical methods are applied, work products are produced, milestones are established, quality is ensured, and change is properly managed.
Methods:
Software engineering methods provide the technical aspects for building software.
Methods encompass a broad array of tasks that include communication, requirements analysis, design
modeling, program construction, testing, and support.
Software engineering methods rely on the set of modeling activities and other descriptive techniques.
Tools:
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 CASE ( computer-aided software engineering), is established.
(2) Process & Generic Process Model
A software process is defined as a collection of work activities, actions, and tasks that are performed
when some work product is to be created.
Each of these activities, actions, and tasks reside within a framework or model that defines their
relationship with the process and with one another.
Figure: Generic Process Model
(3) Umbrella Activities
Software engineering process framework activities are complemented by a number of umbrella
activities.
In general, 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 and control —allows the software team to assess progress against the project plan
and take any necessary action to maintain the schedule.
Risk management —assesses risks that may affect the outcome of the project or the quality of the product.
Software quality assurance —defines and conducts the activities required to ensure software quality.
Technical reviews —assesses software engineering work products in an effort to uncover and remove errors
before they are propagated to the next activity.
Measurement —defines and collects process, project, and product measures that assist the team in
delivering software that meets stakeholders’ needs; can be used in conjunction with all other framework and
umbrella activities.
Software configuration management —manages the effects of change throughout the software process.
Reusability management —defines criteria for work product reuse (including software components) and
establishes mechanisms to achieve reusable components.
Work product preparation and production —encompasses the activities required to create work products
such as models, documents, logs, forms, and lists.
(4) Prescriptive Process Models
Prescriptive process models were originally proposed to bring order to the chaos of software
development.
Traditional models have brought a certain amount of useful structure to software engineering work and
have provided a reasonably effective road map for software teams.
Following are prescriptive process models:
̶J Waterfall model ̶J Incremental Model RAD Model ̶J Evolutionary Process Model Prototype Model Spiral Model Concurrent Process Model
(5) Waterfall Process Model
The waterfall model, sometimes called the classic life cycle, suggests a systematic, sequential approach to software development that begins with customer specification of requirements and progresses through planning, modeling, construction, and deployment, culminating in ongoing support of the completed software.
Limitations :
Figure: Waterfall Model
The nature of the requirements will not change very much during development; during evolution.
The model implies that you should attempt to complete a given stage before moving on to the next
stage.
Does not account for the fact that requirements constantly change.
It also means that customers cannot use anything until the entire system is complete.
The model implies that once the product is finished, everything else is maintenance.
Surprises at the end are very expensive
Some teams sit ideal for other teams to finish
Therefore, this model is only appropriate when the requirements are well-understood and changes will
be fairly limited during the design process.
When to use waterfall model?
Requirements are very well known, clear and fixed
Product definition is stable
Technology is understood
There are no ambiguous requirements
Ample resources with required expertise are available freely
The project is short
Generates working software quickly and early during the software life cycle.
This model is more flexible – less costly to change scope and requirements.
It is easier to test and debug during a smaller iteration.
In this model customer can respond to each built.
Lowers initial delivery cost.
Easier to manage risk because risky pieces are identified and handled during iteration.
Disadvantages:
Needs good planning and design.
Needs a clear and complete definition of the whole system before it can be broken down and built
incrementally.
Total cost is higher than waterfall.
When to use waterfall model?
This model can be used when the requirements of the complete system are clearly defined and
understood.
Major requirements must be defined; however, some details can evolve with time.
There is a need to get a product to the market early.
A new technology is being used.
Resources with needed skill set are not available.
There are some high risk features and goals.
(7) RAD (Rapid Application Development) Process Model
It is a type of incremental model. In RAD model the components or functions are developed in parallel as
if they were mini projects.
The developments are time boxed, delivered and then assembled into a working prototype.
This can quickly give the customer something to see and use and to provide feedback regarding the
delivery and their requirements.
Figure: Rapid Application Development Model
Advantages:
Reduced development time.
Increases reusability of components
Quick initial reviews occur
Encourages customer feedback
Integration from very beginning solves a lot of integration issues.
Disadvantages:
For large but scalable projects RAD requires sufficient human resources.
Projects fail if developers and customers are not committed in a much shortened time-frame.
Problematic if system cannot be modularized.
Not appropriate when technical risks are high (heavy use of new technology).
When to use RAD model?
RAD should be used when there is a need to create a system that can be modularized in 2-3 months of
time.
It should be used if there’s high availability of designers for modeling and the budget is high enough to
afford their cost along with the cost of automated code generating tools.
RAD SDLC model should be chosen only if resources with high business knowledge are available and
there is a need to produce the system in a short span of time (2-3 months).
When to use Prototype Model?
Prototype model should be used when the desired system needs to have a lot of interaction with the end
users.
Typically, online systems, web interfaces have a very high amount of interaction with end users, are best
suited for Prototype model. It might take a while for a system to be built that allows ease of use and needs minimal training for the end user.
Prototyping ensures that the end users constantly work with the system and provide a feedback which is
incorporated in the prototype to result in a useable system. They are excellent for designing good human computer interface systems.
(9) Spiral process model
It was originally proposed by Barry Boehm, the spiral model is an evolutionary software process model
that couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model.
It provides the potential for rapid development of increasingly more complete versions of the software.
The spiral development model is a risk-driven process model generator that is used to guide multi-
stakeholder concurrent engineering of software intensive systems.
It has two main distinguishing features. One is a cyclic approach for incrementally growing a system’s
degree of definition and implementation while decreasing its degree of risk.
The other is a set of anchor point milestones for ensuring stakeholder commitment to feasible and
mutually satisfactory system solutions.
Figure: Spiral Process Model
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 the customer after delivery.
In addition, the project manager adjusts the planned number of iterations required to complete the
software.
Advantages:
High amount of risk analysis hence, avoidance of Risk is enhanced.
Good for large and mission-critical projects.
Strong approval and documentation control.
Additional Functionality can be added at a later date.
Software is produced early in the software life cycle.
Disadvantages:
Can be a costly model to use.
Risk analysis requires highly specific expertise.
Project’s success is highly dependent on the risk analysis phase.
Doesn’t work well for smaller projects.
When to use spiral process model?
When costs and risk evaluation is important for medium to high-risk projects.
Long-term project commitment unwise because of potential changes to economic priorities
Users are unsure of their needs.
Requirements are complex
New product line Significant changes are expected (research and exploration)
(10) Concurrent Process Model
The concurrent development model, sometimes called concurrent engineering, allows a software team
to represent iterative and concurrent elements of any of the process models.
For example, the modeling activity defined for the spiral model is accomplished by invoking one or more
of the following software engineering actions: prototyping, analysis, and design.
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.
All software engineering activities exist concurrently but reside in different states.
Figure: Concurrent Process Model
(13) Product and Process
If the process is weak, the end product will undoubtedly suffer.
But a compulsive overreliance on process is also dangerous.
People derive as much (or more) satisfaction from the creative process as they do from the end product.
An artist enjoys the brush strokes as much as the framed result.
A writer enjoys the search for the proper metaphor as much as the finished book.
As creative software professional, you should also derive as much satisfaction from the process as the
end product.
The duality of product and process is one important element in keeping creative people engaged as
software engineering continues to evolve.
Unit-2 –Agile Development
(1) Agility and Agile Process Model
Agility:
Agility is dynamic, content specific, aggressively change embracing, and growth oriented
It encourages team structures and attitudes that make communication (among team members, between
technologists and business people, between software engineers and their managers) more simplistic.
It emphasizes rapid delivery of operational software and de-emphasizes the importance of intermediate
work products.
It recognizes that planning in an uncertain world has its limits and that a project plan must be flexible.
Agility can be applied to any software process.
Agile Process:
Any agile software process is characterized in a manner that addresses a number of key assumptions
[1] It is difficult to predict in advance which software requirements will persist and which will change. It is equally difficult to predict how customer priorities will change as the project proceeds. [2] For many types of software, design and construction are interleaved. That is, both activities should be performed in tandem so that design models are proven as they are created. It is difficult to predict how much design is necessary before construction is used to prove the design. [3] Analysis, design, construction, and testing are not as predictable as we might like.
Agility 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.
3 Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to
the shorter timescale.
4 Business people and developers must work together daily throughout the project.
5 Build projects around motivated individuals. Give them the environment and support they need, and
trust them to get the job done.
6 The most efficient and effective method of conveying information to and within a development team is
face-to-face conversation.
7 Working software is the primary measure of progress.
8 Agile processes promote sustainable development. The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
9 Continuous attention to technical excellence and good design enhances agility.
10 Simplicity—the art of maximizing the amount of work not done—is essential.
11 The best architectures, requirements, and designs emerge from self– organizing teams.
12 At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its
behavior accordingly.
Agile Process Models:
Extreme Programming (XP)
Adaptive Software Development (ASD)
Dynamic Systems Development Method (DSDM)
Scrum
Crystal
Feature Driven Development (FDD)
Agile Modeling (AM)
- Keeps the developers focused on the problem at hand
Needs continuous integration with other portions (stories) of the s/w, which provides a “smoke testing”
environment
Testing:
Unit tests should be implemented using a framework to make testing automated. This encourages a
regression testing strategy.
Integration and validation testing can occur on a daily basis
Acceptance tests, also called customer tests, are specified by the customer and executed to assess
customer visible functionality
Acceptance tests are derived from user stories
Adaptive Software Development (ASD)
Adaptive Software Development (ASD) is a technique for building complex software and systems. ASD focus on human collaboration and team self-organization. ASD incorporates three phases Speculation, Collaboration, and Learning.
Speculation:
Figure: Adaptive Software Development
“Speculate” refers to the planning paradox—outcomes are unpredictable, therefore, endless
suppositions on a product’s look and feel are not likely to lead to any business value.
The big idea behind speculate is when we plan a product to its smallest detail as in a requirements up
front Waterfall variant, we produce the product we intend and not the product the customer needs.
In the ASD mindset, planning is to speculation as intention is to need.
Collaboration:
Collaboration represents a balance between managing the doing and creating and maintaining the
collaborative environment.”
