1. SOFTWARE ENGINEERING MCS-2 LECTURE # 3

2. SOFTWARE PROCESS  A software development process, also known as a software development life- cycle (SDLC), is a structure imposed on the development of a software product.  Software Processes include those activities, methods, practices and transformations that are used to create and maintain software products.  Having efficient software processes in an organization can lead to benefits such as cost savings, improved software quality and faster time to market.  There is no ‘ideal’ software process.

3. COMMON ACTIVITIES OF ALL SOFTWARE PROCESSES  S/w Specification / Requirement Engineering  The functionality of the software and constraints on its operation must be defined.  S/w Design & Implementation  The software to meet the specification must be produced.  S/w Validation  The software must be validated to ensure that it does what the customer wants.  S/w Evolution  The software must evolve to meet changing customer needs.

4. SOFTWARE PROCESS MODEL / SOFTWARE PROCESS PARADIGM  A software process model is a  description of the sequence of activities carried out in an SE project, and  the relative order of these activities.  A software process model is a standardized format for planning organizing, and running a development project.  A software process model is a simplified representation of a software process.  Each process model represents a process from a particular perspective, and thus provides only partial information about that process.

5. LINEAR SEQUENTIAL MODEL / WATER FALL MODEL  The waterfall model is a sequential design process, often used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases.  The waterfall model is the classic process model – it is widely known, understood and used.  In some respect, waterfall is the ”common sense” approach.  Each phase is performed in turn, and we do not move to the next stage until we have completed the current stage. At the end of each stage a decision will be made as to whether to continue with the project or to scrap the project.

6. STEPS / PHASES OF WATER FALL PROCESS MODEL  Requirement Gathering & Analysis  This is the starting phase of the SDLC in which all possible system requirements are captured & analyzed. Software requirements specification includes the complete information about how actual end users are expecting from the system.  System & Software Design  Prior to start actual coding, it is mandatory to be aware of what all features we are going to implement & how it would look like?  Implementation  Upon getting the system design specifications document the actual coding would be started.

7. STEPS OF WATER FALL PROCESS MODEL  Integration & Testing  All the units developed in the implementation phase are integrated into a system after testing of each unit. Post integration the entire system is tested for any faults and failures. Upon complete testing of software is done then actual Software is successfully send to customer.  Operations & Maintenance  This phase is the never ending phase of the Waterfall Model. The problems come in picture after Implementation & Unit Testing phase.

8. ADVANTAGES OF WATER FALL PROCESS MODEL  Simple to use and easy to understand.  Works well in situations where requirements, once defined, will not change.  Because of the linear and strict nature of the model it is easy for project managers to enforce.  Widely used and known (in theory!)  Fits other engineering process models: civil, mech etc.  Reinforces good habits: define-before-design, design-before-code  Works well on large/mature products and weak teams.  Identifies deliverables and milestones  Document driven: People leave, documents don’t

9.  Does not work well in environments where requirements will continually change up to the point at which the software is in use.  Working software is not expected to be produced until the very end of the life cycle. There is thus substantial risk that the software will not meet the exact needs of the customer.  Doesn’t reflect iterative nature of exploratory development.  Sometimes unrealistic to expect accurate requirements early in a project  Software is delivered late, delays discovery of serious errors.  Difficult and expensive to change decisions, ”swimming upstream”.  Significant administrative overhead, costly for small teams and projects. DISADVANTAGES OF WATER FALL PROCESS MODEL

10. WHEN TO USE WATER FALL MODEL?  The project is simple and short.  The project is complicated, but you have the expertise to deliver it.  The upfront investment is not risky to make.  You focus your performance measures on delivery date and budget.  There are no ambiguous requirements. Requirements are very well known, clear and fixed.  Product definition is stable.  Technology is understood.  Ample resources with required expertise are available freely.  You work for a big client and they enforces their very formal approach on vendors.  You work on fixed-scope, fixed-price contracts and client doesn't expect (for any reasons) rapid change in the scope.

11. GOOD LUCK ! ☻