Presentation is loading. Please wait.

Presentation is loading. Please wait.

Software Development Process

Similar presentations


Presentation on theme: "Software Development Process"— Presentation transcript:

1 Software Development Process
Unit 1 12 marks

2 Definition of Software
Software is: 1. Instructions (computer programs) that when executed provide desired features, function, and performance; 2. Data structures that enable the programs to adequately manipulate information, and 3. Descriptive information (documents) in both hard copy and virtual forms that describes the operation and use of the programs.

3 Characteristics of software
Software is developed or engineered; it is not manufactured in the classical sense. The two activities (software development and hardware manufacturing) are fundamentally different. In both activities, high quality is achieved through good design, but the manufacturing phase for hardware can introduce quality problems.

4 Software doesn’t “wear out.” But it does deteriorate!
During its life, software will undergo change. As changes are made, it is likely that errors will be introduced, causing the failure rate curve to spike as shown in the “actual curve” . Before the curve can return to the original steady-state failure rate, another change is requested, causing the curve to spike again. Slowly, the minimum failure rate level begins to rise—the software is deteriorating due to change.

5 Although the industry is moving toward component-based construction, most software continues to be custom built.

6 Categories of software /changing nature of software
System software  It is collection of programs written to service other programs. Some system software (e.g., compilers,editors, and file management utilities) processes complex, but determinate, information structures.  Other systems applications (e.g., operating system components, drivers, networking software process largely indeterminate data. Application software  Stand-alone programs that solve a specific business need.  Applications in this area process business or technical data in a way that facilitates business operations or management/technical decision making

7 Engineering/scientific software  Applications range from astronomy to volcanology, from automotive stress analysis to space shuttle orbital dynamics, and from molecular biology to automated manufacturing  E.g.: CAD software. Embedded software  Resides within a product or system and is used to implement and control features and functions for the end user and for the system itself.  Embedded software can perform limited functions (e.g., key pad control for a microwave oven) or provide significant function and control capability (e.g., digital functions in an automobile such as fuel control, dashboard displays, and braking systems).  E.g. Control buttons of washing machine.

8 Product-line software  Designed to provide a specific capability for use by many different customers.  Product-line software can focus on a limited marketplace (e.g., inventory control products) or address mass consumer markets (e.g., word processing, spreadsheets, computer graphics, multimedia, entertainment, database management, and personal and business financial applications). Web applications  Called “WebApps,” this network-centric software category spans a wide array of applications.  In their simplest form, WebApps can be little more than a set of linked hypertext files that present information using text and limited graphics.

9 Artificial intelligence software  Makes use of non-numerical algorithms to solve complex problems that are not amenable to computation or straightforward analysis.  Applications within this area include robotics, expert systems, pattern recognition (image and voice), artificial neural networks, theorem proving, and game playing

10 Software Engineering: A layered technology approach:

11  Software engineering is a layered technology
 Software engineering is a layered technology. Referring to, any engineering approach (including software engineering) must rest on an organizational commitment to quality. The bedrock that supports software engineering is a quality focus.  The foundation for software engineering is the process layer. The software engineering process is the glue that holds the technology layers together and enables rational and timely development of computer software. Process defines a framework that must be established for effective delivery of software engineering technology.

12  The software process forms the basis for management control of software projects and establishes the context in which technical methods are applied, work products (models, documents, data, reports, forms, etc.) are produced, milestones are established, quality is ensured, and change is properly managed. Software engineering methods provide the technical how-to’s for building software.

13  Software engineering tools provide automated or semi-automated support for the process and the methods. When tools are integrated so that information created by one tool can be used by another, a system for the support of software development, called computer-aided software engineering, is established.

14 The software process framework /framework activities:
 A process framework establishes the foundation for a complete software process by identifying a small number of framework activities that are applicable to all software projects, regardless of their size or complexity.  In fig each framework activity is populated by a set of software engineering actions. A collection of related tasks that produces a major software engineering work product. Each action in process framework is populated with individual work tasks that accomplish some part of the work implied by the action

15 1. Communication: Communication framework activity involves heavy communication and collaboration with the customer, encompasses requirements gathering, data gathering and other related activities. 2. Planning: Planning activity establishes a plan for software engineering work that follows. Planning describes the technical tasks to be conducted, the resources that will be required, schedule, and the risks that are likely in the work products to be produced.

16 3. Modeling: Modeling activity encompasses the creation of models that allow the developer and the customer to better understand software requirements specifications and the design that will achieve those requirements. There are two types of modeling i.e. analysis modeling and design modeling.

17 4. Construction: Construction activity combines code generation and the testing. 5. Deployment: The software is delivered to the customers who evaluates the delivered product and provides feedback based on the evaluation.

18

19 Umbrella Activities: Generic views of SE is complemented by a set of unbrella activities. They are Software Project tracking and control: It allows the software team to access progress against the project plan and takes necessary action to maintain schedule. Umbrella activities occur throughout the software process and focus primarily on project management, tracking and control.

20 Risk Management: Assess risks that are likely to affect performance and quality of project. Software quality assurance: Define and conduct activities to ensure software quality

21 Formal Technical Review: Assess Software Engg
Formal Technical Review: Assess Software Engg. Work products to uncover and remove errors before they are shifted to next level of activity. Measurement: Defines and collects process, project and product measures to assist the team in delivering the software that meets customer needs can be used in conjunction with all framework and umbrella activities

22 Software configuration Management (SCM): Manages and effects the changes throughout the software process. Reusability management: Defines criteria for work product reuse (including software components) and establishes the mechanism to achieve reusable components. Work product preparation and production: Includes activities for creating work product such as models, documents, large

23 Prescriptive Process Models:
Irrespective of which level of CMM the organization has, the software engineer has five choices for selection of software process models. They are – 1. Waterfall Model 2. Incremental Model 3. RAD Model 4. Prototype Model 5. Spiral Model

24 The Waterfall Model:

25  Communication: It involves heavy communication with the customer (or stakeholder) and encompasses requirement gathering and related activities.  Planning: In this activity, effort required, cost/budget, risk analysis ,time duration are estimated (project plan is made)  Modeling: This activity creates analysis and design models that both developers and customer to better understand the requirements. Data structure, software architecture and other details are made.  Construction: This activity performs code generation and testing to ensure whether requirements are fulfilled. Code generation is done first and then testing is done after that.  Deployment: Once the product is fully developed, it is delivered to the customer. Customer evaluates the product and provides feedback.

26 one stage should be completed before the other begins.
All phases are clearly defined. Being oldest, this is one of the time tested Methods Real projects rarely follow sequential model. It is often difficult for the customer to state all requirements explicitly. The working model is available only in the latter part of the development.

27 This model presents a high level view and suggests to the developer the sequence of events they should expect to encounter. This model is used to prescribe software development activities in variety of contexts. One of the biggest limitation is it does not reflect the way code is really developed.

28 Advantages:  It is the simplest software process model
Advantages:  It is the simplest software process model.  Easy to understand  Phases are completed one at a time  Works well for smaller projects

29 Disadvantages:  Real projects rarely follow the sequential flow that the model proposes. Although the linear model can accommodate iteration, it does so indirectly. As a result, changes can cause confusion as the project team proceeds.  It is often difficult for the customer to state all requirements explicitly. The waterfall model requires this and has difficulty accommodating the natural uncertainty that exists at the beginning of many projects.  The customer must have patience. A working version of the program(s) will not be available until late in the project time span. A major blunder, if undetected until the working program is reviewed, can be disastrous.

30 The Incremental Model:

31 Situation in which incremental model is applicable:
The incremental model combines elements of linear and parallel process flows. There are many situations in which initial software requirements are reasonably well defined, but the overall scope of the development effort prevents a purely linear process. When an incremental model is used, the first increment is often a core product. That is, basic requirements are addressed but many supplementary features (some known, others unknown) remain undelivered.

32 Few of the steps are defined
It is iterative in nature. New model for development It provides on the rigid nature(fixed) of sequential approach This method is of great help when organization is low on staffing. This model could be time consuming.

33 Advantages:  Useful when staffing is unavailable  Less costly to change the scope of the project  Customer can respond to each build. Disadvantages:  Cost is higher than waterfall model.  Needs good planning and design

34 The RAD Model:

35 Rapid Application Development (RAD) is a modern software process model that emphasizes a short development cycle. “high-speed” adaptation (Rapid Application Development ) If requirements are well understood and project scope is considered, the RAD process enables a development team to create a “Fully Functional System” within a very short period of time (e.g. 60 to 90 days). This model should be used if domain experts are available with relevant business knowledge.

36 Advantages: Changing requirements can be accommodated and progress can be measured. 2. Powerful RAD tools can reduce development time. 3. Productivity with small team in short development time and quick reviews, risk control increases reusability of components, better quality. 4. Due to risks in new approach only modularized systems are recommended through RAD. 5. Suitable for scalable component based systems.

37 Disadvantages: Success of RAD model depends on strong technical team expertise and skills. 2. Highly skilled developers needed with modeling skills. 3. User involvement throughout life cycle. If developers &customers are not committed to the rapid fire activities necessary to complete the System in a much-abbreviated time frame, RAD projects will fail. 4. May not be appropriate for very large scale systems where the technical risks are high.

38 drawback of RAD model. 1. RAD needs enough human resources to create the required number of RAD teams. 2. If developers and customers are not committed to the rapid model, the RAD project fails. 3. Rapid-fire activities need to be completed in very short or small time frame. Time is the major constraint in RAD. 4. RAD has to be modularized in a proper way otherwise creates a lots of confusions and problems. 5. In case of high performance requirement, RAD cannot be ideal model.

39 The Prototype Model:

40 Situation in which prototyping model is applicable:
Often, a customer defines a set of general objectives for software, but does not identify detailed requirements for functions and features. Prototyping iteration is planned quickly, and modeling (in the form of a “quick design”) occurs. The prototyping paradigm assists you and other stakeholders to better understand what is to be built when requirements are indefinite. The prototyping paradigm begins with communication. You meet with other stakeholders to define the overall objectives for the software, identify whatever requirements are known, and outline areas where further definition is mandatory.

41 Advantages:  Users are actively involved in the development
Advantages:  Users are actively involved in the development.  Users get better understanding of the system being developed.  Errors can be detected much earlier.  Quick user feedback is available. Disadvantages:  Overall software quality or maintainability may not get considered when the prototype is being developed.  An inefficient algorithm may be implemented.  Inappropriate OS or programming language maybe used simply because it is available.

42 The Spiral Model

43 Using the spiral model, software is developed in a series of evolutionary releases. During early iterations, the release might be a model or prototype. During later iterations, increasingly more complete versions of the engineered system are produced. A spiral model is divided into a set of framework activities defined by the software engineering team. Risk is considered as each revolution is made. Each pass through the planning region results in adjustments to the project plan. Cost and schedule are adjusted based on feedback derived from the customer after delivery.

44 Advantages:  The spiral model is a realistic approach to the development of large-scale systems and software.  High amount of risk analysis hence, avoidance of risk is enhanced. Disadvantages:  It may be difficult to convince customers (particularly in contract situations) that the evolutionary approach is controllable.  It demands considerable risk assessment expertise and relies on this expertise for success.  If a major risk is not uncovered and managed, problems will undoubtedly occur.

45 Agile Software Development
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software“ It is an recent approach for Project Management Cycle-time reduction is most important Model focuses on modularity, iterative, time bound, parsimony, adaptive, incremental convergent, collaborative approach Agile process model uses the concept of Extreme Programming

46 Features of the Agile Software Development Approach
Modularity allows a process to be broken into components called activities. Iterative Agile software processes focus on short cycles. Within each cycle, a certain set of activities is completed. Time-Bound set time limits (between one and six weeks is normal) on each iteration and schedule Parsimony require a minimal number of activities necessary to reduce risks and achieve their goals.

47 Adaptive The agile process adapts the process to attack these new found risks.
Incremental partitions the nontrivial system into increments which may be developed in parallel, at different times, and at different rates. Convergent actively attacking all of the risks worth attacking. People-Oriented Developers that are empowered raise their productivity, quality, and performance. Collaborative When a project is developed in pieces, understanding how the pieces fit together is vital to creating the finished product.

48 Agile process

49 Agile Methodologies eXtreme Programming (XP) Scrum
Crystal family of methodologies Feature-Driven Development (FDD) Adaptive Software Development (ASD) Dynamic System Development Model (DSDM) Agile Unified Process (AUP)

50 eXtreme Programming (XP) XP's Four Values
Communication. Most projects fail because of poor communication. So implement practices that force communication in a positive way. Simplicity. Develop the simplest product that meets the customer’s needs Feedback. Developers must obtain and value feedback from the customer, from the system, and from each other. The same as standard Agile values: value customer collaboration over contract negotiation. Courage. Be prepared to make hard decisions that support the other principles and practices. Respect . The agile team inculcates respect among it members, between other stakeholders and team members, and indirectly, for the software itself.

51 The XP Process Extreme Programming uses an object-oriented approach as its preferred development paradigm and encompasses a set of rules and practices that occur within the context of four framework activities: Planning Design Coding Testing

52

53 Industrial XP Joshua Kerievsky [Ker05] describes Industrial Extreme Programming (IXP) in the following manner: “IXP is an organic evolution of XP. It is imbued with XP’s minimalist, customer-centric, test-driven spirit. IXP differs most from the original XP in its greater inclusion of management, its expanded role for customers, and its upgraded technical practices.” IXP incorporates six new practices that are designed to help ensure that an XP project works successfully for significant projects within a large organization.

54 Readiness assessment. Prior to the initiation of an IXP project, the organization should conduct a readiness assessment. The assessment ascertains whether an appropriate development environment exists to support IXP, the team will be populated by the proper set of stakeholders, the organization has a distinct quality program and supports continuous improvement, the organizational culture will support the new values of an agile team, the broader project community will be populated appropriately.

55 Project community. When XP is to be applied for a significant project in a large organization, the concept of the “team” should morph into that of a community. A community may have a technologist and customers who are central to the success of a project as well as many other stakeholders (e.g., legal staff, quality auditors, manufacturing or sales types) who “are often at the periphery of an IXP project yet they may play important roles on the project”

56 Project chartering. The IXP team assesses the project itself to determine whether an appropriate business justification for the project exists and whether the project will further the overall goals and objectives of the organization. Chartering also examines the context of the project to determine how it complements, extends, or replaces existing systems or processes.

57 Test-driven management.
An IXP project requires measurable criteria for assessing the state of the project and the progress that has been made to date. Test-driven management establishes a series of measurable “destinations” and then defines mechanisms for determining whether or not these destinations have been reached.

58 Retrospectives. An IXP team conducts a specialized technical review after a software increment is delivered. Called a retrospective, the review examines “issues, events, and lessons-learned” across a software increment and/or the entire software release. The intent is to improve the IXP process.

59 Continuous learning. Because learning is a vital part of continuous
process improvement, members of the XP team are encouraged (and possibly, incented) to learn new methods and techniques that can lead to a higher quality product.

60 Adaptive Software Development (ASD)

61 Speculation uses project initiation information—the customer’s mission statement, project constraints (e.g. delivery dates or user descriptions), and basic requirements—to define the set of release cycles (software increments) that will be required for the project.

62 Collaboration It encompasses communication and teamwork, but it also emphasizes individualism, because individual creativity plays an important role in collaborative thinking. People working together must trust one another to criticize without hatred, Assist without anger, work as hard as or harder than they do, have the skill set to contribute to the work, discuss problems or concerns in a way that leads to effective action.

63 Learning focus groups , technical reviews, project postmortems.
ASD teams learn in three ways: focus groups , technical reviews, project postmortems. Software developers often overestimate their own understanding (of the technology, the process, and the project) and that learning will help them to improve their level of real understanding.

64 Scrum

65 Scrum itself is a framework for effective team collaboration on complex software projects.
The team is hard working and goal oriented even though it is a small team work. Scrum is a repetitive and incremental framework for project management majorly used in very active software development. The scrum methodology requires openness and trust in the team, which these five values of Scrum support Openness Commitment Courage Respect Focus

66

67 Advantages: Transparency in project development status. Flexibility towards the changes. Improved communication, minimum overhead in development process. Productivity can be improved. Disadvantages: Some decisions are hard to track in fixed time span. There are problems to deal with non-functional requirements of the system.

68 Dynamic Systems Development Method(DSDM)
DSDM is a, Straight forward framework based on best principles to start implementing a project structure. Simple Extendible But not calming to be the solution to all kind of projects.

69

70 Crystal Primary goal of this method is to deliver useful and working software. Crystal is actually comprised of a family of agile methodologies such as Crystal Clear, Crystal Yellow, Crystal Orange and others, whose unique characteristics are driven by several factors such as team size, system criticality, and project priorities. This Crystal family addresses the realization that each project may require a slightly tailored set of policies, practices, and processes in order to meet the project 's unique characteristics.

71 selection criteria for software process model
Type Of the Project Suggested Model small Project Requirements of the project well understand. Existing manual system has to be automated. If no need for customer involvement in project development cycle Waterfall Model

72 Type Of the Project Suggested Model When project requirements are not clear. System will be operated by novice user. The GUI of project is very important. Delivery of the project is expected within a short period of time. RAD Model

73 Type Of the Project Suggested Model When project requirements are not properly known. For the system in which customer involvement is must. The GUI of project is very important. Quick Delivery of the project is expected . Agile Model

74 Type Of the Project Suggested Model The risk of long project is not affordable. Requirements are not known and will be known only with time. Project is of large size. Spiral Model


Download ppt "Software Development Process"

Similar presentations


Ads by Google