Software Engineering & Project Management: Code: C033514

Download as pdf or txt
Download as pdf or txt
You are on page 1of 60

Software Engineering &

Project Management
Code: C033514(033)
INTRODUCTION TO
SOFTWARE ENGINEERING
• IEEE defines software engineering as: The application of a
systematic, disciplined, quantifiable approach to the
development, operation and maintenance of software
Software engineering
principles
Software engineering principles use two important techniques
to reduce problem complexity:
• Abstraction
• Decomposition.
Abstraction: The principle of abstraction implies that a problem
can be simplified by omitting irrelevant details.

Decomposition: a complex problem is divided into several


smaller problems and then the smaller problems are solved one
by one.
Abstraction:
• It is also called model building.
• The principle of abstraction implies that a problem can be
simplified by omitting irrelevant details.

• Example: Develop overall understanding of a country.


You would study an abstraction with the help of map. There are
various types of abstraction for a same problem.
Decomposition:
• A complex problem is divided into several smaller problems
and then the smaller problems are solved one by one.
• Decompose a large problem into small independent parts.
• Example:Try to break a bunch of sticks together, its difficult.
But individual breaking is easier.
• Chapter organization of a book.
Decomposition contd..
• An arbitary decomposition of a problem doesnot
help.Example:
SOFTWARE DEVELOPMENT LIFE CYCLE/The
software Process
Series of Identifiable stages theat a software product undergoes
during its lifetime:
• Feasibility study
• Requirements analysis and specification
• Design
• Coding
• Testing
• Maintainance
Myths

It can be categorized into 3 groups:


• Management Myths
• Customer myths
• Practitioner's myths.
Management Myths:
1-Myth: 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? No.
2-Myth: My people have state-of-the-art software development
tools, after all, we buy them the newest computers.
Reality: ?
3-Myth: If we get behind schedule, we can add more
programmers and catch up.
Reality:?
4-Myth: If I decide to outsource the software project to a third
party, I can just relax and let that firm build it.
Reality: ?
Customer myths

• A customer who requests computer software may be a person


at the next desk, a technical group down the hall, the
marketing/sales department, or an outside company that has
requested software under contract.
1-Myth: A general statement of objectives is sufficient to begin
writing programs— we can fill in the details later.
Reality: A poor up-front definition is the major cause of failed
software efforts
2-Myth: Project requirements continually change, but change
can be easily accommodated because software is flexible.
Reality: It is true that software requirements change, but the
impact of change varies with the time at which it is introduced
Practitioner's myths
• Myths that are still believed by software practitioners have been
fostered by 50 years of programming culture
1-Myth: Once we write the program and get it to work, our job is
done.
Reality:60 and 80 percent of all effort expended on software will be
expended after it is delivered to the customer for the first time.
2-Myth: Until I get the program "running" I have no way of assessing
its quality
Reality: Software reviews are a "quality filter" that have been found to
be more effective than testing for finding certain classes of software
defects.
3-Myth: The only deliverable work product for a successful project is
the working program.
Reality: A working program is only one part of a software configuration
that includes many elements. Documentation is important too.
4-Myth: 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 quality. Better quality leads to reduced
rework. And reduced rework results in faster delivery times
Waterfall Model
classic life cycle model
Feasibility study
Requirements analysis and
specification
• This phase consists of two distinct activities, namely
• Requirements gathering and analysis : The requirements
analysis activity is begun by collecting all relevant data
regarding the product to be developed from the users of the
product and from the customer through interviews and
discussions. After all ambiguities, inconsistencies, and
incompleteness have been resolved and all the requirements
properly understood, the requirements specification activity
can start
• Requirements specification: The user requirements are
systematically organized into a Software Requirements
Specification (SRS) document
Design
• The goal of the design phase is to transform the requirements
specified in the SRS document into a structure that is suitable
for implementation in some programming language.
• Traditional design approach - Traditional design consists of
two different activities; first a structured analysis of the
requirements specification is carried out where the detailed
structure of the problem is examined. This is followed by a
structured design activity. During structured design, the
results of structured analysis are transformed into the
software design.
• Object-oriented design approach -In this technique, various
objects that occur in the problem domain and the solution
domain are first identified, and the different relationships that
exist among these objects are identified.
Coding and Unit testing
• coding phase is sometimes called the implementation phase.
• translate the software design into source code
• Each component of the design is implemented as a program
module.
• The end-product of this phase is a set of program modules
that have been individually tested.
• During this phase, each module is unit tested to determine the
correct working of all the individual modules.
Integration and system testing
• The modules are integrated in a planned manner.
• Integration is normally carried out incrementally over a
number of steps. During each integration step, the partially
integrated system is tested and a set of previously planned
modules are added to it. Finally, when all the modules have
been successfully integrated and tested, system testing is
carried out.
Integration and System Testing
contd..
• System testing usually consists of three different kinds of
testing activities:
• α – testing: It is the system testing performed by the
development team.
• β –testing: It is the system testing performed by a friendly set
of customers.
• Acceptance testing: It is the system testing performed by the
customer himself after the product delivery to determine
whether to accept or reject the delivered product.
Maintenance
• -Maintenance of a typical software product requires much
more than the effort necessary to develop the product itself.
Maintenance CONTD..
• corrective maintenance:
Correcting errors that were not discovered during the product
development phase.
• perfective maintenance :Improving the implementation of the
system, and enhancing the functionalities of the system
according to the customer’s requirements.
• Adaptive maintenance :Porting the software to work in a new
environment. For example, porting may be required to get the
software to work on a new computer platform or with a new
operating system.
Iterative waterfall model:
THE RAD MODEL
• Rapid application development (RAD) is an incremental
software development process model that emphasizes an
extremely short development cycle.
• rapid development is achieved by using component-based
construction.
• RAD process enables a development team to create a “fully
functional system” within very short time periods (e.g., 60 to
90 days)
RAD CONTD..
RAD Contd..
• The phases in the rapid application development (RAD) model
are:
Business modeling: The information flow is identified between
various business functions.
Data modeling: Information gathered from business modeling is
used to define data objects that are needed for the business.
Process modeling: Data objects defined in data modeling are
converted to achieve the business information flow to achieve
some specific business objective. Description are identified and
created for CRUD of data objects.
Application generation: Automated tools are used to convert
process models into code and the actual system.
Testing and turnover: Test new components and all the
interfaces.
RAD Contd..
Advantages of the RAD model:

• 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 of RAD model:
• Depends on strong team and individual performances for identifying
business requirements.
• Only system that can be modularized can be built using RAD
• Requires highly skilled developers/designers.
• High dependency on modeling skills
• Inapplicable to cheaper projects as cost of modeling and automated
code generation is very high.
RAD Contd..
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).
Incremental model
Incremental model contd..
• Advantages –
• Error Reduction (core modules are used by the customer from
the beginning of the phase and then these are tested
thoroughly)
• Uses divide and conquer for breakdown of tasks.
• Lowers initial delivery cost.
• Incremental Resource Deployment.
• Disadvantages –
• Requires good planning and design.
• Total cost is not lower.
• Well defined module interfaces are required.
Incremental model contd..
• When to use this –
• Funding Schedule, Risk, Program Complexity, or need for early
realization of benefits.
• When Requirements are known up-front.
• When Projects having lengthy developments schedules.
• Projects with new Technology.
PRTOTYPING MODEL
• A prototype is a toy implementation of the system.
• A prototype of the actual product is preferred in situations
such as:
• User requirements are not complete
• Technical issues are not clear
• Advantages –

• This ensures a greater level of customer satisfaction and


comfort.
• New requirements can be easily accommodated as there is
scope for refinement.
• Missing functionalities can be easily figured out.
• Errors can be detected much earlier thereby saving a lot of
effort and cost, besides enhancing the quality of the software.
• The developed prototype can be reused by the developer for
more complicated projects in the future.

• Flexibility in design.
• Disadvantages –

• Costly w.r.t time as well as money.


• There may be too much variation in requirements each time the
prototype is evaluated by the customer.
• Poor Documentation due to continuously changing customer
requirements.
• It is very difficult for developers to accommodate all the changes
demanded by the customer.
• There is uncertainty in determining the number of iterations that
would be required before the prototype is finally accepted by the
customer.
• After seeing an early prototype, the customers sometimes demand
the actual product to be delivered soon.
• Developers in a hurry to build prototypes may end up with sub-
optimal solutions.
• The customer might lose interest in the product if he/she is not
satisfied with the initial prototype.
. EVOLUTIONARY MODEL
• It is also called successive versions model. At first, a simple
working model is built. Subsequently it undergoes functional
improvements & we keep on adding new functions till the
desired system is built.
EVOLUTIONARY MODEL
Contd…
• Applications: Large projects where you can easily find modules
for incremental implementation. Often used when the
customer wants to start using the core features rather than
waiting for the full software. Also used in object oriented
software development because the system can be easily
portioned into units in terms of objects.
• Advantages: User gets a chance to experiment partially
developed system
• Reduce the error because the core modules get tested
thoroughly.
• Disadvantages: It is difficult to divide the problem into several
versions that would be acceptable to the customer which can
be incrementally implemented & delivered.
Evolutionary model VS
Incremental model
• In the Evolutionary model, the complete cycle of activities is
repeated for each version.
• In the Incremental model, Requirements are established
initially. Increments are individually designed, tested, and
delivered at successive points in time.
SPIRAL MODEL/Meta model
• Each loop of the spiral represents a phase of the software
process.
• provides support for Risk Handling.
• Each loop of the spiral is called a Phase of the software
development process.
• The exact number of phases needed to develop the product
can be varied by the project manager depending upon the
project risks
• 4 phases:
• Objectives determination and identify alternative solutions:
• Identify and resolve Risks
• Develop next version of the Product:
• Review and plan for the next Phase
Advantages of Spiral Model:
• Risk Handling: The projects with many unknown risks that occur as
the development proceeds, in that case, Spiral Model is the best
development model to follow due to the risk analysis and risk
handling at every phase.

• Good for large projects: It is recommended to use the Spiral Model


in large and complex projects.

• Flexibility in Requirements: Change requests in the Requirements at


later phase can be incorporated accurately by using this model.

• Customer Satisfaction: Customer can see the development of the


product at the early phase of the software development and thus,
they habituated with the system by using it before completion of the
total product.
Disadvantages of Spiral
Model:
• Complex: The Spiral Model is much more complex than other
SDLC models.

• Expensive: Spiral Model is not suitable for small projects as it


is expensive.

• Too much dependability on Risk Analysis: The successful


completion of the project is very much dependent on Risk
Analysis. Without very highly experienced experts, it is going
to be a failure to develop a project using this model.

• Difficulty in time management: As the number of phases is


unknown at the start of the project, so time estimation is very
difficult.
Object-oriented Life Cycle Model

• The Object-Oriented approach of Building Systems takes the


objects as the basis.
• For this, first the system to be developed is observed and
analyzed and the requirements are defined as in any other
method of system development.
• For example, in the case of a Banking System, a customer is an
object, a chequebook is an object, and even an account is an
object.
• Object-oriented model employs an object-oriented strategy.
The primary objectives are:
• 1. Object-oriented analysis,
• 2. Object-oriented design,
• 3. Object-oriented programming
• There are a variety of object-oriented methodologies such as:
• Object Identification:
System objects and their characteristics and events.
• Object Organization:
Shows how objects are related via “part-of” relationships.
• Object Interfaces:
Shows how objects interact with other objects.
These activities tend to be overlapping and in general and
parallel.
• Advantages of Object-Oriented Life Cycle Model:
• Design is no longer carried out independently of the later
implementation because during the design phase we must
consider which components are available for the solution of
the problem.
• Design and implementation become more closely associated.
• Duration of the implementation phase is reduced.
AGILE Methodology
PRINCIPLES OF AGILE
Advantages
Mehodologies
Scrum

You might also like