System Development Life Cycle (SDLC)

Activities Common to Software Projects Planning : Principles Principle #1. Understand the scope of the project. It’s impossible to use a roadmap if you don’t know where you’re going. Scope provides the software team with a destination. Principle #2. Involve the customer in the planning activity. The customer defines priorities and establishes project constraints (timelines). Principle #3. Recognize that planning is iterative. A project plan is never engraved in stone. As work begins, it very likely that things will change. Principle #4. Estimate based on what you know. The intent of estimation is to provide an indication of effort, cost, and task duration, based on the team’s current understanding of the work to be done. If the information is vague or unreliable, estimates will be equally unreliable. 2

Planning Principles Principle #5. Consider risk as you define the plan. If you have identified risks that have high impact and high probability, contingency planning is necessary. Principle #6. Be realistic. People don’t work 100 percent of every day. Everyone makes mistakes. Principle #7. Define how you intend to ensure quality. The plan should identify how the software team intends to ensure quality. Principle #8. Describe how you intend to accommodate change. Even the best planning can be prevented by uncontrolled change. Principle #9. Track the plan frequently and make adjustments as required. Software projects fall behind schedule one day at a time. 3

© Lethbridge/Laganière 2005 Chapter 1: Software and Software Engineering4 Activities Common to Software Projects Analyze Requirements and specification Includes —Domain analysis —Defining the problem —Requirements gathering -Obtaining input from as many sources as possible —Requirements analysis -Organizing the information —Requirements specification -Writing detailed instructions about how the software should behave

Requirements Background - A requirement is a statement of a behavior or attribute that a system must possess for the system to be acceptable to a stakeholder. - System requirements make explicit the characteristics of the system- to-be. Requirements are usually divided into functional and non- functional. © Lethbridge/Laganière

Types of requirements 1- Functional requirements determine the system’s expected behavior and the effects it should produce in the problem domain. These requirements generally represent the main product features. 2- Non-functional requirements describe some quality characteristic that the system-to-be shall exhibit. They are also known as “quality” or “emergent” requirements, or the “-ilities” of the system-to-be. An example non- functional requirement is: Maintain a persistent data backup, for the cases of power outages. © Lethbridge/Laganière 2005 Chapter 1: Software and Software Engineering6

Requirements Engineering Process Requirements engineering process consists of four phases: Requirements elicitation: getting the customers to state exactly what the requirements are. Requirements analysis: making qualitative judgments and checking for consistency and feasibility of requirements. Requirements validation: demonstrating that the requirements define the system that the customer really wants. Requirements management: the process of managing changing requirements during the requirements engineering process and system development, and identifying missing and extra requirements. © Lethbridge/Laganière 2005 Chapter 1: Software and Software Engineering7

Writing Requirements Requirements always need to be: -Correct -Unambiguous - complete -Consistent -testable. © Lethbridge/Laganière 2005 Chapter 1: Software and Software Engineering8

Recommendations When Writing Requirements Never assume: others do now know what you have in mind. Use meaningful words; avoid words like: process, manage, perform, handle, and support. State requirements not features: - Feature: general, tested only for existence. - Requirement: specific, testable, measurable. Avoid: - Conjunctions: ask yourself whether the requirement should it be split into two requirements. - Conditionals: if, else, but, except, although. - Possibilities: may, might, probably, usually. © Lethbridge/Laganière 2005 Chapter 1: Software and Software Engineering9

© Lethbridge/Laganière 2005 Chapter 1: Software and Software Engineering10 Activities Common to Software Projects Design Deciding how the requirements should be implemented, using the available technology Includes: —Systems engineering: Deciding what should be in hardware and what in software —Software architecture: Dividing the system into subsystems and deciding how the subsystems will interact —Detailed design of the internals of a subsystem —User interface design —Design of databases

© Lethbridge/Laganière 2005 Chapter 1: Software and Software Engineering11 Activities Common to Software Projects 3- Modeling Creating representations of the domain or the software —Use case modeling —Structural modeling —Dynamic and behavioural modeling 4- Programming or implementation 5- test, maintenance, support

Activities Common to Software Projects Other Activities : - Quality assurance Reviews and inspections Testing Deployment Managing the process © Lethbridge/Laganière 2005 Chapter 1: Software and Software Engineering12

© Lethbridge/Laganière 2005 Chapter 1: Software and Software Engineering Difficulties and Risks in Software Engineering Complexity and large numbers of details Uncertainty about technology Uncertainty about requirements Uncertainty about software engineering skills Constant change Deterioration of software design Political risks

Risk management Background Project management is the process of planning and controlling the development of a system within a specified timeframe at a minimum cost with the right functionality. Risk Management - Risk management is concerned with identifying risks and drawing up plans to minimize their effect on a project. - A risk is a probability that some adverse circumstance will occur. - Project risks which affect schedule or resources. - Product risks which affect the quality or performance of the software being developed. - Business risks which affect the organization developing the software. © Lethbridge/Laganière 2005 Chapter 1: Software and Software Engineering14

Risk management Risk Management Process - Risk identification: identify project, product and business risks. - Risk analysis: assess the likelihood and consequences of these risks. - Risk planning: draw up plans to avoid or minimize the effects of the risk. - Risk monitoring: monitor the risks throughout the project. © Lethbridge/Laganière 2005 Chapter 1: Software and Software Engineering15

Deliverables of the SDLC Begin building new system System converted Users trained Coded and Tested System Design Specifications Preliminary Investigation System Analysis System Design System Implementation System Development System Maintenance Approved Feasibility Study Operational System Documentation completed Abort Project Goto next phase Goto Previous phase Problem Specifications

Home work Consider the following problem You are hired to develop an automatic patient monitoring system for a home-bound patient. The system is required to read out the patient’s heart rate and blood pressure and compare them against specified safe ranges. The system also has activity sensors to detect when the patient is exercising and adjust the safe ranges. In case an abnormality is detected, the system must alert a remote hospital. (Note that the measurements cannot be taken continuously, since heart rate is measured over a period of time, say 1 minute, and it takes time to inflate the blood-pressure cuff.) The system must also (i) check that the analog devices for measuring the patient’s vital signs are working correctly and report failures to the hospital; and, (ii) alert the owner when the battery power is running low. © Lethbridge/Laganière 2005 Chapter 1: Software and Software Engineering17

Tasks 1- Write the requirements for this system and prioritize them. 2- Identify the possible risks and manage them. © Lethbridge/Laganière 2005 Chapter 1: Software and Software Engineering18