Se 1-2

1. System
A bigger group of entities/things involved to accomplish a set of specific/particle 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

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 completed MED 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 accept: SK]
N. Tasks, jobs, jobs
Verification
N. (TERM)
(1). The act of verifying or the state of being verified.
Proof: proof of action or status verified
(2). A confirmation of truth or authority.
Verification: Confirmation of truth or power
(3). The eviion for such a confirmation.
Evidence: evidence of such evidence
(4). A formal assertion of validity.
Validation: formal assertions of effectiveness
(5). Law an affidavit that attests to the truth of a pleading.
[Law] oath: a vow to prove a complaint is true)
Measurement
N. Measurement, measurement [pl.] size, size

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: specified 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 available 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 extends Human Resources
In case system is not properly modularized, integration of modules may create problems

8. The needs (or requirements) of the customer cocould 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 dimo-
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
Alibaba 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?
Complete translation of specified ented 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 your 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 design test cases
Horizontal traceability: ensures all requirements are inreceivated into product
Vertical traceability: ensures no unnecessary functionality is supported ded 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 events des: Identifying configuration items, identifying naming conventions, defining the workflow, defining the storage structure, defining back-up mechanisms
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 shoshould 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 your 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's 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's TS while testing
Use relevant tools for testing, do need e the option of Automatic 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'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 valid tive
Better Way of permission cing 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 versions of use, consistency of deliverables, version control, release control and back-up mechanisms