Module-1: Software Engineering
Module-1: Software Engineering
EID303
SOFTWARE ENGINEERING
A.NAVYA SREE
ASSISTANT PROFESSOR
DEPARTMENT OF CSE
SYLLABUS
Characteristics of Software:
(1)Software is developed or engineered. It is not manufactured.
-Some similarities exist between software development and hardware
development (or) manufacturing, but two activities are different.
- In both activities high quality is achieved through good design.
-Quality problems occur in hardware manufacturing which are difficult to
remove.
-During software development it can be easily rectified.
-In both activities developers are responsible for providing quality products.
(2)Software doesn’t wear out.
- In hardware development process the failure rate is very high because of
manufacturing defects.
-If the defects are corrected the failure rate reduces.
-As the time passes the failure rate increases due to the environmental maladies
[Eg: temperature, dust and vibrations].
In software there will be no environmental maladies (or) changes so the
curve should be idealized. But due to the changes and undiscovered errors the failure rate
will be high and when errors are corrected it drops.
Software Product:
Software when developed (or) made for a specific requirement.
Engineering:
Developing products using certain principles and methods.
Application software:
Engineering/scientific software:
-This software is used to facilitate the engineering/scientific functions and tasks.
-Computer-aided design, system simulation, and other interactive applications
have begun to take real-time and even system software characteristic.
Embedded software:
Web -applications:
-It is a client-server computer program which the client runs on the web
browser.
-Data on the Internet is in the form of text, audio, or video format, linked with
hyperlinks.
-Web browser is a software that retrieves web pages from the Internet.
Artificial intelligence software:
SOFTWARE MYTHS
Myth:
A widely held but false belief or idea, typically involving supernatural beings or
events. Myths appear to be reasonable statement of fact but when comes to reality it
changes.
Software Myths:
False beliefs about software and the process that is used to build it. Software
myths are of three types:
➢ Management myths
➢ Customer myths
➢ Practitioner’s myths
(1) Management myths:
Myth- We already have a book that’s full of standards and procedures which are
enough for building software.
Reality- Standards are often incomplete. If they are complete, developers may not be
aware of all the established standards. It doesn’t reflect modern software engineering
practices.
Myth- If we get behind schedule, we can add more programmers and catch up.
Reality- Adding new people to the project, further delays the project as people who are
already working must spend time educating the newcomers. People can be added but only
in a planned and well coordinated manner.
Myth - Outsourcing the software project to third party, we can relax and let that them
build it.
Reality- Outsourcing software to a third party does not help the organization, which is
incompetent in managing and controlling the software project internally.
(2)Customer myths:
Myth- General Statement of objective is enough to begin writing programs, the details
can be filled in later.
Reality- Incomplete and ambiguous requirements often lead to software failure. A formal
and detailed description of the functions, behavior, performance, interfaces, design
constraints, and validation criteria is essential.
(3)Practitioner’s myths:
Myth - Once the program is written, the job has been done.
Reality- All the efforts are expended after the software is delivered to the user, for
maintaining, adding new requirements and so on.
Myth - Until the program is running, there is no way of assessing the quality.
Reality- The quality of software can be measured during any phase of development
process by applying some quality assurance mechanism. One such mechanism is formal
technical review.
Myth - The only deliverable work product is the working program
Reality- A successful project which is delivered includes not only the working program
but also the documentation to guide the users for using the software.
Methods:
- Provide technical how-to’s for building software.
- Methods contain a broad array of tasks that include communication requirement
analysis, design modeling, program construction testing and support.
Tools:
- Provide semi-automatic and automatic support to process and methods. [ i.e.,
CAD]
Figure: Layers of Software Engineering
DEFINITIONS:
Process: Collection of activity, action, task that are performed when some work product
is created.
Activity: An activity strives to achieve a broad objective and is applied regardless of the
application domain, size of the project, complexity with which software engineering is to
be applied.
Action: An action encompasses a set of tasks that produces a major work product.
Task: A task focuses on a small, but well-defined objective that produces a tangible
outcome.
A PROCESS FRAMEWORK
Establishes the foundation for a complete software process.
Identifies a number of framework activities applicable to all software projects.
Also include a set of umbrella activities that are applicable across the entire software
process.
Used as a basis for the description of process models.
Figure: A Software Process Framework
Umbrella activities:
➢ Software project tracking and control:
-In this activity, the developing team accesses project plan and compares it with
the predefined schedule.
-If these project plans do not match with the predefined schedule, then the
required actions are taken to maintain the schedule.
➢ Risk management:
- Assesses risks that may affect the outcome of the project or the quality of the
product.
➢ Measurement:
- Defines and collects process, project, and product measures.
- Measures like cost, lines of code, size of software, quality of software etc.
➢ Software configuration management:
- The activities required to create work products such as models, documents, logs,
forms, and lists.
Continuous Model:
-Lets organization select specific improvement that best meet its business objectives and
minimize risk
-Levels are called capability levels.
-Describes a process in 2 dimensions.
-Each process area is assessed against generic, specific goals and practices and is rated
according to the following capability levels.
-Set of activities (or) areas that are clubbed together.
Levels of CMMI
-Level 0: Incomplete: Process is adhoc .Objectives and goals of process areas are not
achieved.
-Level 1: Performed: All the specific goals of the process area have been satisfied.
-Level 2: Managed: Activities are monitored, reviewed, evaluated and controlled.
-Level 3: Defined: Activities are standardized, integrated and documented.
-Level 4: Quantitatively Managed: Metrics and indicators are available to measure the
process and quality.
Staged Model:
-This model is used if you have no clue of how to improve the process for quality
software.
-It gives a suggestion of what things other organizations have found helpful to work first.
-Levels are called maturity levels.
CMMI currently addresses three areas of interest:
PROCESS FLOW
Linear process flow: A linear process flow executes each of the five framework activities in
sequence.
Iterative process flow: The five framework activities are done in iterative fashion.
Evolutionary process flow: An evolutionary process flow executes the activities in a “circular”
manner (combination of iterative and linear).Each circuit leads to a more complete version of the
software.
Parallel process flow: A parallel process flow executes one or more activities in parallel with
other activities.
PROCESS MODELS
Process model is a diagrammatic representation, description of each phase and various
activities required to make a software product. Various process models are:
➢ The Waterfall Model
➢ Incremental Process Models
➢ Evolutionary Process Models
Advantages:
-Simple to implement.
-For implementing small systems waterfall model is useful.
- Easy to arrange tasks.
Disadvantages:
-Real projects rarely follow the sequential flow that the model proposes.
-It is difficult for the customer to state all the requirements explicitly.
- Users can only judge quality at the end.
- Risk and uncertainty is high with this process model.
-Waterfall model leads to “blocking states”.
Advantages:
- Productivity with in short time.
- Progress can be measured.
- Cycle time can be short with use of powerful RAD tools.
Disadvantages:
-For the project, large number of people or sufficient human resources is required
to create the teams.
-Heavy commitment of the developers and customers is required otherwise RAD
project fails.
-High performance is an issue.
-RAD may not be appropriate when technical risks are high.
-If a system cannot be properly modularized, building the components necessary
for RAD will be problematic.
-Used when customer defines a set of objective but does not identify input, output, or
processing requirements.
-Developer is not sure of:
➢ Efficiency of an algorithm.
➢ Adaptability of an operating system.
➢ Human/machine interaction.
-In a rush to get it working, overall software quality or long term maintainability
are generally overlooked.
-Use of inappropriate Operating system or programming language.
-Use of inefficient algorithm
The Spiral Model:
-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.
-The spiral model is divided into a number of framework activities.
-These framework activities are denoted by task regions.
-Starts in middle and continually visits the basic tasks of communication,
planning, modeling, construction and deployment.
-Realistic approach to the development of large scale system and software.
-Software evolves as process progresses.
-Better understanding between developer and customer.
-The first circuit might result in the development of a product specification.
-Subsequent circuits develop a prototype and sophisticated version of software.
Unlike other process models that end when software is delivered, the
spiral model can be adapted to apply throughout the life of the computer software.
Therefore, the first circuit around the spiral might represent a “concept
development project” that starts at the core of the spiral. The process proceeds
outward on the spiral and a “new product development project” commences.
Later, a circuit around the spiral might be used to represent a “product
enhancement project”. Later, a circuit around the spiral might be used to
represent a “product maintenance project”.
Disadvantages: