Unit 1 Introduction and SDLC Models PDF

This document is for private circulation only, For T. Y. Computer 2024-25 CCEW students. Subject: Software Design and Architecture PLEASE refer TO ALL REFERENCES plus Study Material CIRCULATED. Feel free to use additional web sites/searches for understanding if required.  ACKNO...

This document is for private circulation only, For T. Y. Computer 2024-25 CCEW students. Subject: Software Design and Architecture PLEASE refer TO ALL REFERENCES plus Study Material CIRCULATED. Feel free to use additional web sites/searches for understanding if required.  ACKNOWLEDGEMENT This presentation contains pictures, contents taken from multiple sources, authors and sites. We would like to appreciate and thank the authors, artists and do not claim any of following work to be ours, but it has been compiled here to use for academic purpose only.  Scope / Topics Software Application Domains – Examples Digital Transformation – Concept, Examples Real World Software development – Features, Examples Characteristics of software Challenges of software development Quality of software  Scope / Topics Software Development Life Cycle (SDLC) - Software Development phases - SDLC models: Waterfall/Classic Life Cycle, Incremental, Iterative. - Examples, Comparison SRS – various points - Purpose, Goal, In scope, Not in scope - Product perspective, Operating environment - Features, Major services, Functional requirements - Design and Implementation constraints, External interfaces - Nonfunctional requirements, Use persona etc. Software Design and Architecture Introduction / Context Software is everywhere….  Software Application Domains System Software Application Software Engineering / Scientific Embedded Software Software Web Applications Product-line Software Artificial Intelligence Software  Examples Banking Government Manufacturing Education Travel Entertainment Communication Law… Defense Safety critical systems Medicine Mission critical systems Research Digital Transformation Digital Transformation Digital Transformation Digital Transformation Digital Transformation – Few More Examples Social networking – Instagram, Linkedin etc. Online meetings Smart Agriculture Rich set of features through online banking … …  Real World Software Naive users Formal business contracts Lifetime in years Software that is likely to evolve and to change Development in teams, not by individuals Careful specification prior to product design  Real World Software Development User-friendly Different platforms Naive users Documentation Likely to evolve Quality Reliability Security Incredibly complex Teams Formal business contracts Rigorous testing Lifetime in years  Real World Software Need for user-friendly interfaces Need for various forms of documentation (including user manuals) Egoless programming - Working in team, mutual respect, peer reviews Software that is incredibly complex as compared to academic software  Real World Software Formalized product reviews and quality assurance measures Formalized, rigorous testing procedures Product may need to run on different platforms Reliability may be a matter of life or death; or the cost of failure might lead to an economic catastrophe  Real World Software Issues of security may be extremely important [CIA = Confidentiality, Integrity, Availability] Ethical issues (like protecting privacy) may be extremely important Many different kinds of people might have a vested interest in a product, its costs, and its efficacy (vendors, clients, users)  Incredibly Complex Nature Demands Engineering Techniques in the Production of Software How Software Development is different Software is not manufactured in the traditional sense. Software costs are concentrated in engineering (development) and not in production. Software does not wear out (in the physical sense). Software has no replacement parts. How Software Development is different Software maintenance is a difficult problem. Much of the software is custom-built. The causes of software failure may be difficult to detect or to remove. Estimating the probability of failure can be very difficult. Many legal issues need to be resolved. (e.g. intellectual property rights, liability)  Quality Software Correctness (it satisfies its specifications) Timeliness (it is developed in time to benefit various constituencies) Robustness (it can function under abnormal situations) Reliability (this is defined to be correctness + robustness)  Quality Software Adaptability (graceful evolution; the cost of maintenance is acceptably low) Reusability (software components can be utilized in other projects) Interoperability (software can be combined with other software systems in a convenient manner) Efficiency (various cost metrics are acceptably low) User-friendliness (rewards of using the system are commensurate with the effort required to both learn and to use the system in practice)  Quality Software Portability (can be moved to new hardware platform with acceptably low cost; can be moved to a new compiler...) Security (cannot be accessed, modified or damaged by unauthorized users) Efficacy (complete and efficient functionality relative to the problems that the system is designed to solve) Why is software development so difficult? User expectations Communications The mythical man-month factor Project characteristics: – size / complexity – novelty of the application – response-time characteristics – security requirements – user interface requirements – reliability / criticality requirements – hardware complexity  Positive Software Innovations Compilers Databases Embedded software Internet Search engines Web browsers Spreadsheets …  Negative Software Innovations Computer viruses, spy ware Pop-up adds Spam Phishing Software Development Phases  Software Development Phases Requirements gathering Planning Analysis and Design Development or coding Testing Deployment and Maintenance  SDLC consists of a detailed plan describing how to develop, maintain, replace and alter or enhance specific software. SDLC describes various phases of software development and the order of execution of phases.  SDLC Phases Requirements gathering – Business analyst along with project team members sets up a meeting with the client to gather all the data like what the customer wants to build, who will be the end user, what is the objective of the product/software. – Once the requirements are understood, the SRS document is created. SRS document is reviewed by the customer and it is followed by all the team members in the project.  SDLC Phases Planning – Planning of resources such as software, hardware, HR – Estimation of time, budget, training cost etc. – Identification of risks Testing – After the code is generated, it is tested against the requirements to make sure that the project is solving the needs addressed and gathered during the requirements stage. Software Development Life Cycle Models - How phases combine together to form a complete life cycle Waterfall Model / Classic Life Cycle Model Requirements Gathering Planning Analysis and Design Development Testing Deployment Waterfall Model / Classic Life Cycle Model Model is simple and easy to understand and implement. Reinforces the notion of “define before design” and “design before code”. Waterfall Model / Classic Life Cycle Model The model expects complete and accurate requirements early in the process, which is unrealistic. It is difficult to define all requirements at the beginning of a project. Model is not suitable for accommodating any change. A working version of the system is not seen until late in the project’s life. It does not scale up well to large projects. Testing is done at the end only. Involves high risk of failure and uncertainty. Sequential model => teams cannot work in parallel. Real projects are rarely sequential !!  Incremental Model Rather than deliver the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality. User requirements are prioritised and the highest priority requirements are included in early increments. Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve.  The Incremental Model increment # n Co m m u n i c a t i o n Pl a n n i n g M o d e l i n g analy s is Co n s t ru c t i o n des ign c ode De p l o y m e n t t es t d e l i v e ry fe e d b a c k deliv ery of increment # 2 nt h increment Co m m u n i c a t i o n Pl a n n i n g M o d e l i n g analy s is Co n s t ru c t i o n des ign c ode De p l o y m e n t t es t d e l i v e ry fe e d b a c k deliv ery of increment # 1 2nd increment Co m m u n i c a t i o n Pl a n n i n g M o d e l i n g analy s is Co n s t ru c t i o n des ign c o de deliv ery of De p l o y m e n t t est d e l i v e ry fe e d b a c k 1st increment project calendar t ime  Incremental Model - Advantages Customer value can be delivered with each increment so system functionality is available earlier. Early increments act as a prototype to help elicit requirements for later increments. Lower risk of overall project failure. The highest priority system services tend to receive the most testing. Iterative Model  Iterative Model In this Model, it starts with some of the software specifications and develops the first version of the software. After the first version if there is a need to revise the software, then a new version of the software is created with a new iteration. Every release of the Iterative Model finishes in an exact and fixed period that is called iteration.  Iterative Refinement Evaluation Requirements Implementation (prototype) Design Source: Internet  ACKNOWLEDGEMENT This presentation contains pictures, contents taken from multiple sources, authors and sites. We would like to appreciate and thank the authors, artists and do not claim any of above work to be ours, but it has been compiled here to use for academic purpose only.