Definition: It is a systematic, disciplined, cost effectiveness techniue for Software developent. Engineering appoach to develop a Software.
Characteristics:

• Correctness
• Usability
• Reliability
• Efficiency
• Maintainability
• Portability
• Scalability
• Security
• Modularity
• Reusuability
• Testibility

SDLC: planning -> analysis (SRS) -> design -> code -> testing -> deploy -> planning
Waterfall model: feasibility study -> requirement analysis and specifications -> design -> coding and unit testing -> System testing and integration -> maintainance
Advantages: i) Base model ii) simple and easy iii) small projects
Disadvantages: i)No feedback ii) No experiment iii) no paralleism iv) High risk v) 60% efforts in maintainance.
Iterative waterfall model: sae as waterfall but after maintainance feedback will inclde in all part except study.
V model in SDLC:

1. Known as verification and validation model
2. Extension of waterfall model
3. testing is associated with every phase.
4. verification phase (Reqirement analysis, system design, architecture design, module design)
5. Validation phase (unit testing, integration, system, acceptance testing)

Advantages:

1. time saving
2. Good understanding of project in the beginning
3. every component must be feasible
4. progress can be tracked easily

Disadvantages:

1. no feedback so less scope of changes
2. Risk analysis not done
3. Not good for big or object oriented project.

Prototype model:

1. Csutomer not clear with idea can understand a prototype
2. Throwaway model
3. Good for technical and reqiurement risks.
4. Increase in cost of development.

Incremental model:

1. module by module.
2. Customer interaction maximum.
3. large projects
4. early release product demand
5. fleible to demand

Evolutionary model

1. Evolutionary model is a cobination of Iterative and Incremental model of SDLC.
2. Incremental model first implement a few basic features and deliver to the Csutomer and then build the next part and do the sae and continue.
3. Iterative odl ain Advantages is its feedback in every process
4. Also known as "design a little, bild a little, test a little, deploy a little"

Advantages:

1. Cstoer reuirement are clearly specified
2. Risk analysis is better
3. It suupports changing environent
4. Initial operating tie is less

Disadvantages:

1. Not siutable for saller projects
2. cost
3. highly skilled resorces reuired

Spiral model:

1. objecive determination and identfy alternative solutions.
2. identify and resolve risks
3. develop next version of product.
4. Review and plan for next phase.
5. radis of spiral = cost
6. anglar dimension = progress

Agile technology: Big pojects breaks into smaller part.
Advantages:

1. Freqent delivery
2. Face to face communication
3. changes
4. time

Disadvantages

1. less documentation
2. maintainance problem

SCRUM model:

1. One of the most popular agile methodology
2. Scrum is lightweight, Iterative, and incremental framework.
3. Scrum breaks down the development phases into stages or cycles called "sprints"
4. The developent time for each sprint is maximized and dedicated, thereby managing only one sprint at a time.
5. Scrum Team has scrum master and product owner with cons
6. Keywords: Backlog, Sprint, daily Scrum, scrum master, product owner

Advantages:

1. Freedom & adaption
2. high-quality, low-risk product.
3. Reduce the development time up to 40%.
4. Scrum customer satisfaction is very important
5. reviweing the current sprint before moving to new one.

Disadvantages:

1. More efficient for small team size.
2. No changes in the sprint.

Software requirement

1. It is the description of features and functionalities of the target system.
2. It is the description of what the system should do.
3. requirement Engineering(RE) refers to the process of defining, documentation, maintaining reqiurement in the Engineering design process.
4. it is a four step process, which includes
   • feasibility study
   • Reqirement gathering
   • Software reqiurement specifications
   • Software reqiurement validation

Tool support for requirement Engg

• Observation Reports (user Observation)
• Question interviews, surveys and polls
• use case
• user stories
• Requirement workshops
• Mind mapping
• Role-playing
• Prototyping

Functional and non functional reqiurements

• Reqirements which are related to functional/Working aspect pf Software fall into this category.
• Non-functional reqiurements are exprected characteristics of target software. (security, storage, configuration, performance, cost, interoperability, flexibility, disaster recovery)

SRS (Software Reqirement Specifications)

• SRS is a description of a software system to be developed.
• it lays out functional and non-functional requirement to be develop.
• It may include a set of use cases that describe user interactions that the software must provide to the user for perfect interaction.

SRS structure

1. Introduction
1. Purpose
2. Intended Audience
3. Scope
4. Definitions
5. References
2. Overall description
1. User Interfaces
2. Systemm Interfaces
3. Constraints, assumptions and dependencies
4. User characteristics
3. system features and reqiurement
1. Functional Reqirements
2. use cases
3. External Interface requirement
4. Logical database reqiurement
5. Non-functional reqiurement
4. Deliver for approval

User requirement

• Easy and simple to operate
• Quick response
• effectively handling operational errors
• customer support

user requirement specifications

• It defines what the user expects the software to be able to do.
• It is a contractual aggrement.

Software design

• Interface design
• Architectural design
• Details design

Modularity Breaks into smaller module and handle them. Coupling: one module is dependent on another. low Coupling is best.

Coupling
• data
• stamp
• control
• external
• common
• content

Cohesion: it's a functional strength between module. High cohesion is best.
DFD (Data Flow Diagram)

• A graphical tool useful for communicating with managers and other personel.
• useful for analyzing existing as well as proposed systems.
• Focus on the movement of data between external entities and processes, and between processes and data store.
• A relatively simple technique to learn and use.

Why DFD?

• What data a system process
• What transformations are performed
• What data are stored
• What results are produced
• Graphical nature makes it a good communications tool between -> i) user and analyst ii) Analyst and system designer

**DFD elements

• Source/Sinks (external links)
• Data flows
• Processes
• Data Stores

External links

• A rectangle represents an external entity
• They either supply or receive data
• They do not process data
Source:Entity that supples data to the system. Sink:Entity that receives data from the system.

**Rules of data flow

• Data can flow from
• External entity to process
• Process to external entity
• process to store and back
• process to process
• Data cannot flow from
• External entity to external entity
• External entity to store
• Store to external entity
• Store to store

Logocal and physical DFD

• DFDs considered so far are called logical DFDs
• A physical DFD is similar to a document flow diagram
• It specifies who does the operations specified by the logical DFDs.
• Physical DFD may depict physical movemments of goods.
• Physical DFDs can be drawn during fact gathering phase of a life cycle.

Software design approaches

• Function orient design
• System is designed from a functional viewpoint.
• Top-down decomposition
• Divide & conquer approach
• DFD is used
• Object Orient Design
• System is viewed as a collection of objects
• Bottom-up approach
• UML is used.

SPM (software project manager)

• Software project management is a art and science of planning and leading software projects.
• Main goal is to enable a group of developers to work effectively towards successful completion of project.
• Project manager is an administrative leader of the team.
• Various factors make this job very complex (complexity, uniqueness, possibility of multiple solutions)

Black box/validation and white box/verification testing
Software quality factor can be divided into two categories: i) first, ii) second category
Charcateristics of quality assurance

• Standards
• Quality Attributes
• Continuous Improvement
• Metrics
• Training
• Documentation

Classic model of software quality factor i) Product operation(Correctness, Reliability, Usability), ii) Product revision(Maintainability, flexibility), iii) product transition(Portability, Reusuability) Capability Maturity Model CMM is a strategy to improve the software process and generate quality software. The term "maturity" relates to the degree of formality and optimization of process.
5 levels are there

• lvl1(initial)
• lvl2(managed)
• lvl3(defined)
• lvl4(managed quality)
• lvl5(optimization)

Estimation model: Here we estimate about two things time and cost of developemnt.
Has four types:

1. Post
2. Base
3. Decomposition
4. Empirical

Post Estimation: In case of fiendly party or known technology we do not estimate either time or cost.
Base Estimation: we predict the cost and time of the entire project based on the experience.
Decomposition: used in large project where decomposition of the problem into smaller problem.
Two types: i) Direct extimation(white box), ii) Indirect Estimation(Black box).
Direct Estimation

• Effort = Size / Productivity
• cost = Effort * Pay
• Team Size = Effort / Duration

Indirect estimation

• 2D
  1. Unadjustable
  2. adjustable
• 3D

COCOMO (1981)Construction Cost Model is widely used estimation technique. it is a regression-based model.

• organic
• Semidetached
• Embedded

Organic Relatively small group work in a familier environent to develop well understood program.
Semidetached project team consists of a mixture of experienced and inexperienced stuff. It is of medium size.
Embedded the s/w is strongly coupled to complex h/w, such as traffic control, ATM's or weapon system. The project team is large, a great deal of innovation required. three types of COCOMO

• basic
• Intermediate
• Detailed

Basic COCOMO formula

• D _E = a _b KLOC ^{b _b}
• D _D = C _b (D _E) ^{d _b}
• Team Size = D _E / D _D

Testing

• Unit
• Integration
• System
• Acceptance

Unit testing: first level of testing involves all individual components. Integeration Testing: Indivisual modules are grouped together and tested as a group. N.B (stub module):(top-bottom) stub module may be used to simulate the effect of lower level modules. N.B (driver module):(bottom-up) driver module may be used to simulate the effect of higher level modules. if we mix two approach then it is sandwich /hybrid approach. System testing: here complete and integrated software is tested as a whole and compare with srs document. User Acceptance testing: It involves all functional and non-functional requiremnt are successfully handled or not.