SE 1-2

1.System
A bigger group of entities/things involved to accomplish a set of specific/particular functions
Software
Includes programs, procedures, rules and related documentation
Packs and delivers “Information”

2.Software Crisis
Time and Cost Slippage
Failure at Customer’s site
Untraceable Errors after delivery
Difficulty in Maintenance
Increase in program size and complexity led to

The Software Crisis:
In the early years of computer applications, the focus of development and innovation was on hardware ? software was largely viewed as an afterthought. Computer programming was an art, at best an arcane practice known to a gifted few. Programmers did not follow any disciplined or formalised approaches ? these were confined to hardware designers.

This way of doing things was adequate for a while, until the sophistication of computer applications outgrew this rough-hewn approach. Software soon took over more and more functions which were hitherto done manually or were hard-automated.  As “software houses” emerged, software began to be developed for widespread distribution. Software development projects produced thousands of source program statements. With no tools or methods of managing this increasing complexity, the number of errors began to accelerate. But the personalised nature of programming made maintenance, or the fixing of these errors, exceedingly difficult. The following situation resulted:
Software projects were taking a lot longer than initially envisaged.
Software was costing a lot more to develop than at first estimated.
Software was being delivered to the customer only to fail.
Errors found by the customer were extremely difficult to track down and fix.

These problems are collectively referred to as the “software crisis”. Clearly, there was a need to rethink software development practices. The consensus which emerged was to borrow ideas about systematic development from another discipline, namely engineering.

3.“Software Engineering” is the application of a systematic, disciplined, quantifiable approach to the development,

4.Software Development Life Cycle (SDLC)
Regardless of exact model or framework used, all Software Development Life Cycle methodologies broadly follow the following Steps.
Requirements Analysis
Design
Build
Testing
Deployment
Maintenance

5.Structure of the processes at Infosys: We have adopted the ETVX-M model that will ensure all aspects of a process are covered.

ETVX-M model means :
Entry, Task, Verification & Validation and Exit - Measurement
Entry :  Involves Planning and Training activities
Task  :  Activities/tasks to be performed for that stage
V&V :  Includes reviews, testing
Measurements for effort and defects are taken for every stage.
Every stage also needs commitment for process improvements .

ETVX-M (Entry, Tasks, Verification, Exit – Measurement) Model is used at Infosys for all the review processes

(task  [tɑ:sk]
n.任务，工作，作业
verification 
n.（名词）
(1). The act of verifying or the state of being verified.
证明；证实：证明的行为或被核实的状态
(2). A confirmation of truth or authority.
核实，核查：对真理或权力的确认
(3). The evidence for such a confirmation.
证词：对这类证实的证据
(4). A formal assertion of validity.
确定，鉴定：对效力的正式断言
(5). Law An affidavit that attests to the truth of a pleading.
【法律】 宣誓供词：证明某一申诉属实的宣誓书)
measurement 
n.衡量，测量[ pl.]尺寸，大小

6.Why follow Process ?
If you DON’T follow process :
Non usable outputs (customer dissatisfaction)
Rework is high (cost overruns)
Cost more than estimated and hence less profitable (cost overruns)
Losing Client (Loss of Goodwill and business)

If you follow process:
Usable outputs
No re-work or less rework
Profitable as cost was as per expectations
Happy client
Repeat business

7.Software Process Models are called as Software Development Life Cycles (SDLCs)
Example:
Waterfall Model:No change in requirements ,Deliverables expected at every stage,Systematic execution
 Pros:
 Simple and systematic model
 Follows a disciplined approach
 Cons:
 Limited or no scope for accommodating new requirements
 Potential delay in identifying the risks which might lead to disastrous / terrible results
Prototype Model:Complete set of requirements not available ,Start development with a set of requirements,Feel of the    product with initial requirements expected
 Pros:
 Less technical risks
 Scope for accommodating new requirements
 A part of product is visible at an early stage itself
 Cons:
 Expensive
 Time Consuming
Spiral Model::Many risks are expected ,There are alternatives,Not fixed budget project
 Pros:
 Model for the other models (Meta Model)
 Captures potential risks at an early stage 
 Iterative and realistic model
 Cons:
 Requires good expertise in risk management and project planning
 In this model, projected cost is revisited and revised every round during Planning. Therefore, if Management  demands fixed-budget development, this model may not be suitable
RAD Model:Less than 3 months for launch of the product ,There are many functionalities,Users have to be involved  through out
 What is RAD Model ?
 Rapid Application Development
 Emphasis is on short development time. Completing system development within a short time (60 days to 90  days)
 Each major function addressed by a separate RAD team
 Users are involved throughout the development life cycle
 Pros:
 Working model of software is visible early
 Continuous stream of documentation is maintained for future upgrades
 Cons:
 At times the design standards may be ignored
 For Large Projects, RAD requires many human resources
 In case system is not properly modularized, integration of modules may create problems

8.The needs (or requirements) of the customer could be classified as functional, performance, reliability, maintainability, safety and security, interoperability, cost, schedule etc.

9.Structured System Analysis and Design (SSAD)
Analysis stage produces a structured requirements specification made of graphical notations 
 process model comprising of a set of data flow diagrams
 set of process specifications
 data model comprising of an entity-relationship diagram
 data-dictionary
Design stage refines the findings of the analysis stage to a greater extent, to make sure that it is easily understood 
 Database Design
 Program Design
SSAD uses a set of tools and techniques to model user requirements. Modeling is done to represent and document the requirements gathered. In SSAD, the system is viewed as being composed of two components namely processes and data .Each of these (processes and data) are modeled more or less separately in the Analysis Stage. Graphical Notations are used for modeling purpose. In the design stage, these are further refined and described.

In SSAD, the system is viewed as being composed of two components, functionality and data, each of which is modeled more or less separately.
Functionality are modeled using a technique called process modeling.
Data is modeled using a technique called data modeling.
Since SSAD models functionality and data separately, we say that it follows a function/data methodology
It is more suitable for data intensive projects

10.Object Oriented Analysis and Design (OOAD)
Object Oriented Analysis
 Examines requirements from the perspective of classes and objects existing in the vocabulary of problem domain
 Example: Use case Diagrams
Object Oriented Design
 Process of object-oriented decomposition and a representation for depicting (showing) the system under design
 Example: Class Diagrams

11.Software Construction (Implementation)
 Coding functions or classes using a computer language and using the right set of tools
 Selecting control structures and organizing them
 Polishing code by formatting and commenting it
 Tuning code to enhance the performance
 Eliminating compilation errors and link errors
 Making the executable code

PS:Recap of DAY - 1
Engineering approach was adopted for Software Development to address the “Software Crisis”
Engineering approach uses Processes, Methods and Tools
Many Software Process Models are in use like Waterfall, Prototype, Spiral and RAD Models
SSAD and OOAD are popular Analysis and Design Methodologies
Software Construction involves Coding and Unit Testing

12.How to find defect in Software Artifacts ?
Reviews (evaluation)
 Requirements Review
 Design Review
 Code Review
 Code-walk-through
Testing
 Unit testing
 Integration testing
 System testing
 Acceptance testing
 Functional testing
 Performance testing
 Regression testing

13.There are 2 kinds of formal reviews conducted at Infosys
One-Person Review (OPR) and Group Review (GR)
Doing Self Review (informal review) is a good practice before conducting the OPR or GR.

14.Code Reviews
Why Code Reviews?
 100% code coverage
 2 to 5 times more defects
 Mix of errors like maintainability can be detected
 Reviews & testing go together
What  to look for   ?
 Complete translation of documented specification
 Adherence to defined standards
 Code maintainability
 Hard coded  values in configuration files
Code Walk Through (CWT) ensures 100% code coverage whereas the best run tests cover only 50-70% of the code.
Programmers can find 2 to 5 times as many defects per hour in reviewing programs as they can in test.
CWT finds a mix of errors that testing doesn’t 
e.g. maintainability
Reviews and Testing are complementary .

Any values hard coded which are otherwise expected to come in thru online screens or Configuration files must also be looked for during code reviews

15.At Infosys, how the following are made sure?
Requirements asked by the customer have been really implemented in the software
Requirements have been really tested before delivery of the software to the customer
The delivered software is not having a functionality not asked by the customer

16.Importance of traceability:
To ensure that no requirements are missed
Helps while doing reviews
Helps during designing test cases
Horizontal Traceability:ensures all requirements are incorporated into product
Vertical Traceability:ensures no unnecessary functionality is included unless specifically called for by a requirement
Traceability is an important activity of Requirements Management.

17.At Infosys, how the following are ensured?
Deliverables to the customer are consistent with each other
Right version of software is delivered to the customer
Software is intact inspite of the failure of the development system (and reformatting of the hard disk)

Configuration Management (CM)
Visual Source Safe (VSS) is a Configuration Management tool used in some projects at Infosys
CM Planning includes:identifying configuration items,identifying naming conventions,defining the workflow,defining the storage structure,defining back-up mechanism
Configuration Management Planning  is done by the Configuration Controller

18.Testing is to find defects, not to show the functionality of the software

PS:Qualities of a Tester:Destructively creative,Good detective skills,Possess skeptical but not hostile attitude,Ability to place herself in user’s shoe,Good understanding of domain,Eye for details

19.Test Planning : Testing and the life cycle
Phase   Deliverables
Requirements Analysis------------User Acceptance Plan, System Test Plan
HLD----------------------------------Integration Test Plan
DLD----------------------------------Unit Test Plan
Coding-------------------------------Unit Tested code
Testing-------------------------------Integrated and System tested code
Acceptance--------------------------Sign -off by the customer
Test plan should be developed as early as possible in software development life cycle. 

User acceptance test plan and System test plan can be written immediately after requirements gathering is complete.
During High Level Design (HLD) , the modules of the project and their interfaces get defined. So after HLD, integration plan can be written.
During Low Level Design (LLD), all the program specifications are prepared. So after LLD, Unit test plans can be written for each module.

20.There are different levels of testing:
Unit Testing
Integration Testing
System Testing
Acceptance Testing
Each of this level will test a phase of SDLC

21.Integration Testing :Top Down ,Bottom Up ,Sandwich ,Big Bang
Big Bang is not advised because :
 It is difficult to debug
 It results in a much throwaway code
 Critical and peripheral modules are not distinguished
 Requires all resources for testing to be present in one go
 The user does not see the product until very late in the life cycle

22.System Testing
Functional Testing  - tests the implementation of the business needs
 Test cases are selected based on the functional specification (requirements)
 Also termed as Black Box Testing
 Example: System Testing
(Structural Testing
 Test cases are selected based on the software structure or implementation
 Also termed as White Box Testing
 Example: Unit Testing)
Performance Testing - tests the non-functional requirements of the system like the speed, load etc
Performance Testing:
 Load Testing :
Testing with many users accessing the system at the same time 
 Stress Testing:
Testing to identify the number of users the system can handle at a time before breaking down
 Endurance Testing
: Testing for a long time for reliability
 Spike Testing
:The system is stressed for a short duration

23.Do’s & Don'ts while Coding
 Follow coding guidelines / standards
 Use relevant (related) tools (Integrated Development Environments)
 Do self review before submitting the code for peer reviews
 Spend adequate time on understanding the requirements, test cases before you start coding
 Update the relevant artifacts as and when necessary like Design, SRS, user manual etc
 Develop the code for optimized performance
 Ensure the code adheres to the design
Do’s & Don'ts while Testing
 Use relevant tools for testing, do explore the option of automated testing
 Spent adequate time on understanding the requirements, test cases before you start testing
 Have adequate test data & test environment to do test your code
 Ensure you have a testing server to test your application. Avoid testing in your machine.
 Update the relevant artifacts as and when necessary like test cases & test results, user documentation etc
 Check the code for optimized performance

24.What do we mean by “Quality Software” ?
No simple answer - depends on who is answering the question !

25.What are the impacts of Bad Quality?
Loss of Goodwill
Loss of Business from a Client
Cost Overruns
Irreparable Damages

26.Quality Control and Quality Assurance
Quality Control (QC):
 Focus is on the Product
 QC measures a product against the existence of a required attribute
 Major QC activity is identifying defects  and correcting them (Rework)
 Inspections, Reviews and Testing activities
Quality Assurance (QA):
 Focus is on the Process rather than Product
 QA ensures “Fitness for Purpose”
 Auditing and Reporting functions
 Building process guidelines, checklists and templates
 Training activities
 Building systems and tools for execution
QA and QC at Project Level
QA:
 Ensuring that Project Management Plan is followed
  Defining the project process through the project plan
 Technology and Business domain training
 Doing audits
QC:
 Requirements, design and code reviews
  Functional Testing
  Non-functional testing
  Rework

27.Verification and Validation (V&V)
Verification (proof):
 Activities that ensure that software correctly implements a function
 Addresses whether the software reflects the specified requirements
Validation (support)
 Activities that ensures that software is traceable to customer requirements
 Demonstrates (shows) that the software fulfills intended (proposed) use in intended environment

28.How to do “Defect Prevention” ?
Learn from past projects
Do defect prevention regularly
 Form DP teams and train them
 Classify defects & draw Pareto’s Chart
 Identify root causes for Defects
 Identify appropriate solutions
 Deploy solutions & validate results
Measure the improvement

29.Types of Defects:Logical,User Interface,Maintainability,Standards

PS:Recap of DAY - 2
Defect Detection activities are intended for identifying the defects in the software
Rework to be carried out to eliminate defects
Defect Detection activities are time consuming and marginally effective
Better way of Reducing defects is by preventing the injection of defects (DP)
Traceability ensures that the requirements have been designed, implemented and tested
CM is needed to store the configuration items for ease of use, consistency of deliverables, version control, release control and back-up mechanisms