Lecture 4 - The Software Development Life Cycle -> Quick Intro -> Idea -> Product Design -> Coding: Part 1 -> Coding: Part 2 -> Testing And Bug Fixes -> Release -> Maintenance -> The Big Picture Of The Cycle -> Lecture Recap -> Questions & Exercises
1. The software development life cycle is the process of taking a desired software product from the idea stage to the release of the actual software and its maintenance.
2. Below are main stages of the cycle:
– Idea
– Product design
– Coding
– Testing and bug fixes
– Release
– Maintenance
3. The idea refers to the purpose of the software or its parts. For example, the idea behind YouTube is to enable users to upload, share, and watch videos via the Web.
4. Product design is a description of how to practically implement the software idea(s).
5. The spec must have a unique ID and title. The spec must be assigned a priority. The spec’s priority reflects the importance the company places on the spec’s features. The highest priority is 1; the lowest priority is 4. Programmers and testers must always start working with specs that have the highest priority.
6. The PM should follow seven rules while creating specs:
Rule #1 Clarity of details and definitions.
Rule #2 No room for misinterpretation.
Rule #3 Absence of internal/external conflicts.
Rule #4 Solid, logical structure.
Rule #5 Completeness.
Rule #6 Compliance with laws.
Rule #7 Compliance with business practices.
7. The spec goes through three stages: draft, approval pending, and approved. Only approved specs should be used for programming and test case generation.
8. Approved specs must be frozen and modified in accordance to the spec change procedure.
9. Examples, flowcharts, and mock-ups are excellent tools for illustrating specs.
10. One of the main challenges for the PM is writing specs that allow different people to interpret those specs the same way; i.e., exactly the way the PM intends the specs to be understood.
11. All internal documentation (including specs, test cases, code design documents, procedures, etc.) must be available on the Wiki and optimized for browsing and search.
12. Coding is the translation of the spec or requirements in some other form (for instance, a verbal request from a manager) into a software code.
13. The programmer who creates the code design document does a great favor to himself and the company, because planning allows everyone to see future nuances and prevent bugs.
14. The most common architecture of a Web project consists of:
– The Web server
– The application core
– The database
15. Programmers develop code for the application core.
16. Below are some measures to assist companies to enhance best programming practices and prevent a substantial number of bugs:
– Hire good people, and be prepared to give them a break.
– Facilitate direct, fast, effective communication between coworkers.
– Conduct regular code inspections.
– Develop coding standards.
– Create realistic schedules.
– Ensure the availability of documentation.
– Set rules about unit testing.
– “If it ain’t broke, don’t fix it.”
– Strive to create loyalty.
– Make “quality” and “the happiness of users” fundamental principles of the company philosophy.
17. The cost of the bug refers to how much money the company will lose, depending on when the bug was detected. In some cases when a bug is released to users, the loss to the company can ruin its business.
18. QA and testing should be regarded as business preservation mechanisms.
19. The 2 main activities performed by programmers are:
– Programming
– Bug fixing
20. There are 3 classic types of bugs associated with coding:
– Syntax bugs
– User Interface (UI) bugs
– Logical bugs
21. Syntax bugs are syntactic errors in the code. Syntax bugs are caught by the compiler or interpreter.
22. UI bugs are bugs in presentation.
23. Logical bugs are in processing.
24. Before you start testing, you must check:
– If the code is frozen
– If the test environment has the exact application version that needs to be tested
25. Software code, specs, and test suites must be stored in the CVS (or another version control system)
26. Test case reviews are an extremely useful practice, because they allow PMs and programmers to evaluate and provide feedback about how testers plan to test the software.
27. At the beginning of the “Testing and bug fixes” stage, testers must do a smoke test to check testability of the application. By way of analogy, you cannot test drive a car if the ignition doesn’t work.
28. The 2 main stages of test execution are:
– New feature testing
– Regression testing
29. Feature is a broader term than functionality. Feature refers to:
– The ability to accomplish a particular task
– A specific characteristic of the software
30. Acceptance testing completes the Testing and bug fixes stage and is followed by a Go/No-Go meeting, in which a decision about the release is made.
31. The release is about making product available to the users. In case of beta release, product is made available to the group of selected individuals. In case of public release, product is made available to the general public.
32. A major release is a planned event that generally includes:
– New features
– Bug fixes
– Various modifications to or removal of old features
33. A minor release is either a planned or an unplanned event. As a rule, a minor release is usually a patch release (a release with bug fixes). However, a minor release can also contain new features and/or modifications or removal of old features.
34. A major release is a stage in the company wide SDLC, whereas a minor release can take place during any stage of the SDLC.
35. Bug fixes and various modifications or removal of old features can be considered maintenance.
36. An Emergency Bug Fix (EBF) is a situation where a P1 bug is found in production, and we need to push a patch release ASAP.
37. An Emergency Feature Request (EFR) is a situation where we need to release a certain feature ASAP; e.g., in the case of a court ruling or to comply with a new law.
38. EBF and EFR releases are treated as patch releases. P1 bug must be filed in both cases.
39. A DB refers to containers (DB schema) and the content inside those containers (DB data).
40. CVS branching is an important mechanism that allows us to painlessly roll back to old versions of software and do concurrent programming for multiple releases.
41. A CVS trunk is always OPEN for modifications, but CVS branches are OPEN, CONDITIONALLY OPEN, or LOCKED, depending on stage of the Cycle.
42. Bug postmortems are needed to find out why bugs were missed during testing.
43. Beta releases are needed as marketing and QA measures for 2 reasons:
– To find out if part of the target audience is happy with the product
– To see how the system handles the activities of the beta testers
44. The release should be pushed to production while the majority of the users aren’t using the Web site
45. In some cases, it makes sense to push a release to only one server of the production pool.
46. When there is high activity among users (i.e., seasonal items or the publication of a hot new book), it makes sense to set a moratorium for new releases.
47. Maintenance is an ongoing activity required to support the live site. Next ->
Lecture 4 - The Software Development Life Cycle -> Quick Intro -> Idea -> Product Design -> Coding: Part 1 -> Coding: Part 2 -> Testing And Bug Fixes -> Release -> Maintenance -> The Big Picture Of The Cycle -> Lecture Recap -> Questions & Exercises
