Chapter 2 – Software Engineering Approaches Chapter 2 Software Processes

Chapter 2 Software Processes OVERVIEW A software project Planned undertaking with fixed beginning and end Produces desired result or product Can be a large job with thousands of hours of effort or a small one-month project Successful development project Provides a detailed plan to follow Organized, methodical sequence of tasks and activities Produces reliable, robust, and efficient system Chapter 2 Software Processes

The Systems Development Lifecycle (SDLC) Provides overall framework for managing systems development process Two main approaches to SDLC Predictive approach Adaptive approach

SDLC

Choosing the Predictive vs. Adaptive Approach to the SDLC (Figure 2-1) Systems Analysis and Design in a Changing World, 4th Edition

Adaptive vs. Predictive Methods Adaptive methods focus on adapting quickly to changing realities. When the needs of a project change, an adaptive team changes as well. An adaptive team will have difficulty describing exactly what will happen in the future. The further away a date is, the more vague (uncertain) an adaptive method will be about what will happen on that date. Predictive methods focus on planning the future in detail. A predictive team can report exactly what features and tasks are planned for the entire length of the development process. Predictive teams have difficulty changing direction. The plan is typically optimized for the original destination and changing direction can cause completed work to be thrown away and done over differently. Agile Iterative Waterfall Adaptive Predictive

Traditional Predictive Approach to the SDLC Project planning – initiate, ensure feasibility, plan schedule, obtain approval for project Analysis – understand business needs and processing requirements Design – define solution system based on requirements and analysis decisions Implementation – construct, test, train users, and install new system Support – keep system running and improve

Chapter 2 Software Processes SDLC Organization recognizes problem (project planning) Project team investigates, understands problem and solution requirements (analysis) Solution is specified in detail (design) System that solves problem is built and installed (implementation) System used, maintained, and enhanced to continue to provide intended benefits (support) Chapter 2 Software Processes

SDLC and Problem Solving Organization recognizes problem (project planning) Project team investigates, understands problem and solution requirements (analysis) Solution is specified in detail (design) System that solves problem is built and installed (implementation) System used, maintained, and enhanced to continue to provide intended benefits (support)

“Waterfall” Approach to the SDLC Systems Analysis and Design in a Changing World, 4th Edition

Modified Waterfall Approach with Overlapping Phases (Figure 2-5) Systems Analysis and Design in a Changing World, 4th Edition

Newer Adaptive Approaches to the SDLC Based on spiral model Project cycles through development activities over and over until project is complete Prototype created by end of each cycle Focuses on mitigating risk Iteration – Work activities are repeated Each iteration refines previous result Approach assumes no one gets it right the first time There are a series of mini projects for each iteration Systems Analysis and Design in a Changing World, 4th Edition

The Spiral Life Cycle Model (Figure 2-6) Systems Analysis and Design in a Changing World, 4th Edition

Iteration of System Development Activities (Figure 2-7) Systems Analysis and Design in a Changing World, 4th Edition

INCREMENTAL AND ITERATIVE APPROACHES Systems Analysis and Design in a Changing World, 4th Edition

INCREMENTAL AND ITERATIVE APPROACHES Systems Analysis and Design in a Changing World, 4th Edition

The Unified Process (UP) The Rational Unified Process (RUP) is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003. RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs Systems Analysis and Design in a Changing World, 4th Edition

The Unified Process (UP) Object-oriented development approach Offered by IBM / Rational Booch, Rumbaugh, Jacobson Unified Modeling Language (UML) used primarily for modeling UML can be used with any OO methodology UP defines four life cycle phases Inception, elaboration, construction, transition Systems Analysis and Design in a Changing World, 4th Edition

Rational Unified Process (RUP) involves an iterative, incremental approach to systems development

Activities of Planning Phase of SDLC Let’s return to SDLC and cover it in detail Systems Analysis and Design in a Changing World, 4th Edition

Activities of Planning Phase of SDLC Define business problem and scope Produce detailed project schedule Confirm project feasibility Economic, organizational, technical, resource, and schedule Staff the project (resource management) Launch project  official announcement Systems Analysis and Design in a Changing World, 4th Edition

Activities of Analysis Phase of SDLC Gather information to learn problem domain Define system requirements Build prototypes for discovery of requirements Prioritize requirements Generate and evaluate alternatives Review recommendations with management Systems Analysis and Design in a Changing World, 4th Edition

Activities of Design Phase of SDLC Design and integrate the network Design the application architecture Design the user interfaces Design the system interfaces Design and integrate the database Prototype for design details Design and integrate system controls Systems Analysis and Design in a Changing World, 4th Edition

Activities of Implementation Phase of SDLC Construct software components Verify and test Convert data Train users and document the system Install the system Systems Analysis and Design in a Changing World, 4th Edition

Activities of Support Phase of SDLC Operate system Maintain system Small patches, repairs, and updates Enhance system Small upgrades or enhancements to expand system capabilities Larger enhancements may require separate development project Support users Help desk and/or support team Systems Analysis and Design in a Changing World, 4th Edition

Personnel involved in planning phase: Analyst. User management. Systems management.

Personnel involved in analysis phase: Analyst. User management. User operations workers. Systems management.

Personnel involved in design phase: Analyst. System designer. User management. User operations workers. Systems management.

Personnel involved in implementation phase: Analyst. System designers. Programmers. Systems management. Testers

Personnel involved in support phase: Analyst. System designer. Programmers. User management. User operations workers. Systems management. Testers

The Heart of the Systems Development Process Current practice combines analysis, design, and implementation into a single iterative and parallel process of activities

Waterfall Strengths Easy to understand, easy to use Provides structure to inexperienced staff Milestones are well understood Sets requirements stability Good for management control (plan, staff, track) Works well when quality is more important than cost or schedule

Waterfall Weaknesses All requirements must be known upfront Deliverables created for each phase are considered frozen – inhibits flexibility Can give a false impression of progress Does not reflect problem-solving nature of software development – iterations of phases Integration is one big bang at the end Little opportunity for customer to preview the system (until it may be too late)

When to use the Waterfall Model Requirements are very well known Product definition is stable Technology is understood New version of an existing product Porting an existing product to a new platform.

Waterfall model problems Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements. Therefore, this model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process. Few business systems have stable requirements. The waterfall model is mostly used for large systems engineering projects where a system is developed at several sites. In those circumstances, the plan-driven nature of the waterfall model helps coordinate the work. Chapter 2 Software Processes

V-Shaped SDLC Model A variant of the Waterfall that emphasizes the verification and validation of the product. Testing of the product is planned in parallel with a corresponding phase of development

V-Shaped Steps Project and Requirements Planning – allocate resources Product Requirements and Specification Analysis – complete specification of the software system Architecture or High-Level Design – defines how software functions fulfill the design Detailed Design – develop algorithms for each architectural component Production, operation and maintenance – provide for enhancement and corrections System and acceptance testing – check the entire software system in its environment Integration and Testing – check that modules interconnect correctly Unit testing – check that each module acts as expected Coding – transform algorithms into software

V-Shaped Strengths Emphasize planning for verification and validation of the product in early stages of product development Each deliverable must be testable Project management can track progress by milestones Easy to use

When to use the V-Shaped Model Excellent choice for systems requiring high reliability – hospital patient control applications All requirements are known up-front When it can be modified to handle changing requirements beyond analysis phase Solution and technology are known

Incremental SDLC Model Construct a partial implementation of a total system Then slowly add increased functionality The incremental model prioritizes requirements of the system and then implements them in groups. Each subsequent release of the system adds function to the previous release, until all designed functionality has been implemented.

Incremental Model Strengths 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. Chapter 2 Software Processes

Incremental Model Strengths Develop high-risk or major functions first Each release delivers an operational product Customer can respond to each build Uses “divide and conquer” breakdown of tasks Lowers initial delivery cost Initial product delivery is faster Customers get important functionality early Risk of changing requirements is reduced

Incremental development benefits The cost of accommodating changing customer requirements is reduced. The amount of analysis and documentation that has to be redone is much less than is required with the waterfall model. It is easier to get customer feedback on the development work that has been done. Customers can comment on demonstrations of the software and see how much has been implemented. More rapid delivery and deployment of useful software to the customer is possible. Customers are able to use and gain value from the software earlier than is possible with a waterfall process. Chapter 2 Software Processes

Incremental Model Weaknesses Requires good planning and design Requires early definition of a complete and fully functional system to allow for the definition of increments Well-defined module interfaces are required (some will be developed long before others) Total cost of the complete system is not lower

When to use the Incremental Model Most of the requirements are known up-front but are expected to evolve over time A need to get basic functionality to the market early On projects which have lengthy development schedules On a project with new technology

Supplemental Methods for Predictive Aproaches Prototyping CASE tools Joint Application Design (JAD) Rapid Application Development (RAD) … Agile Methodologies

Chapter 2 Software Processes Software prototyping A prototype is an initial version of a system used to demonstrate concepts and try out design options. A prototype can be used in: The requirements engineering process to help with requirements elicitation and validation; In design processes to explore options and develop a UI design; Chapter 2 Software Processes

Benefits of prototyping Improved system usability. A closer match to users’ real needs. Improved design quality. Improved maintainability. Reduced development effort. Chapter 2 Software Processes

Prototyping Iterative development process: Requirements quickly converted to a working system System is continually revised Close collaboration between users and analysts

Prototype development May be based on rapid prototyping languages or tools May involve leaving out functionality Prototype should focus on areas of the product that are not well- understood; Error checking and recovery may not be included in the prototype; Focus on functional rather than non-functional requirements such as reliability and security Chapter 2 Software Processes

Joint Application Design (JAD) Structured process involving users, analysts, and managers Several-day intensive workgroup sessions Purpose: to specify or review system requirements

Joint Application Design (JAD)

Rapid Application Development (RAD) Methodology to decrease design and implementation time Involves: prototyping, JAD, CASE tools, and code generators

CASE Tools CASE tools are automated, microcomputer-based software packages for systems analysis and design. Four reasons for using CASE tools are: To increase analyst productivity. Facilitate communication among analysts and users. Providing continuity between life cycle phases. To assess the impact of maintenance.

CASE Tools Computer-Aided Software Engineering Software tools providing automated support for systems development Project dictionary/workbook: system description and specifications Diagramming tools Example products: Oracle Designer, Rational Rose, Visible Analyst

CASE tools may be divided into several categories CASE Tool Categories CASE tools may be divided into several categories Upper CASE (also called front-end CASE) tools, used to perform analysis and design. Lower CASE (also called back-end CASE). These tools generate computer language source code from CASE design. Integrated CASE, performing both upper and lower CASE functions.

Upper CASE Upper CASE tools: Create and modify the system design. Store data in a project repository. The repository is a collection of records, elements, diagrams, screens, reports, and other project information. These CASE tools model organizational requirements and define system boundaries.

Lower CASE Lower CASE tools generate computer source code from the CASE design. Source code may usually be generated in several languages.

Advantages of Generating Code Time to develop new systems decreases. The time to maintain generated code is less than to maintain traditional systems. Computer programs may be generated in more than one language. CASE design may be purchased from third-party vendors and tailored to organizational needs. Generated code is free from program coding errors.

Reverse Engineering Reverse engineering is generating the CASE design from computer program code. Source code is examined, analyzed, and converted into repository entities.

Reverse Engineering (Continued) Reverse engineering produces (depending on the tool set used): Data structures and elements, describing the files, records, and field. Screen designs, if the program is online. Report layouts for batch programs. A structure chart showing the hierarchy of the modules in the program. Database design and relationships.

Advantages of Reverse Engineering Reverse Engineering has the following advantages: Reduced system maintenance time. Program documentation is produced for loosely documented programs. Structured programs may be generated from unstructured, older programs. Future system maintenance is easier to implement. Unused portions of programs may be eliminated.

Reuse-oriented software engineering Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems. Process stages Component analysis; Requirements modification; System design with reuse; Development and integration. Reuse is now the standard approach for building many types of business system Chapter 2 Software Processes

Reuse-oriented software engineering Chapter 2 Software Processes

Types of software component Web services that are developed according to service standards and which are available for remote invocation. Collections of objects that are developed as a package to be integrated with a component framework such as .NET or J2EE. Stand-alone software systems that are configured for use in a particular environment. ( e.g. graphic packages ) Chapter 2 Software Processes

AGILE SOFTWARE DEVELOPMENT

Agile methods Dissatisfaction with the overheads involved in software design methods of the 1980s and 1990s led to the creation of agile methods. These methods: Focus on the code rather than the design Are based on an iterative approach to software development Are intended to deliver working software quickly and evolve this quickly to meet changing requirements. The aim of agile methods is to reduce overheads in the software process (e.g. by limiting documentation) and to be able to respond quickly to changing requirements without excessive rework.

Agile manifesto We are uncovering better ways of developing 
software by doing it and helping others do it. 
Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on 
the right, we value the items on the left more.

The principles of agile methods Description Customer involvement Customers should be closely involved throughout the development process. Their role is provide and prioritize new system requirements and to evaluate the iterations of the system. Incremental delivery The software is developed in increments with the customer specifying the requirements to be included in each increment. People not process The skills of the development team should be recognized and exploited. Team members should be left to develop their own ways of working without prescriptive processes. Embrace change Expect the system requirements to change and so design the system to accommodate these changes. Maintain simplicity Focus on simplicity in both the software being developed and in the development process. Wherever possible, actively work to eliminate complexity from the system.  

Agile method applicability Product development where a software company is developing a small or medium-sized product for sale. Custom system development within an organization, where there is a clear commitment from the customer to become involved in the development process and where there are not a lot of external rules and regulations that affect the software. Because of their focus on small, tightly-integrated teams, there are problems in scaling agile methods to large systems.

Problems with agile methods It can be difficult to keep the interest of customers who are involved in the process. Team members may be unsuited to the intense involvement that characterises agile methods. Prioritising changes can be difficult where there are multiple stakeholders. Maintaining simplicity requires extra work.

Agile methods and software maintenance Most organizations spend more on maintaining existing software than they do on new software development. So, if agile methods are to be successful, they have to support maintenance as well as original development. Two key issues: Are systems that are developed using an agile approach maintainable, given the emphasis in the development process of minimizing formal documentation? Can agile methods be used effectively for evolving a system in response to customer change requests? Problems may arise if original development team cannot be maintained.

Scaling agile methods Agile methods have proved to be successful for small and medium sized projects that can be developed by a small co-located team. It is sometimes argued that the success of these methods comes because of improved communications which is possible when everyone is working together.

Choosing a Method Choose either: Plan driven Agile

Chapter 2 Software Processes Choosing a Method In practice, most large systems are developed using a process that incorporates elements from all of these models. The selection of model depends on - Characteristics and complexity of the software - The skills and experience of the members of project groups - Time, budget constraints Chapter 2 Software Processes

Technical, human, organizational issues Most projects include elements of plan-driven and agile processes. Deciding on the balance depends on: Is it important to have a very detailed specification and design before moving to implementation? If so, you probably need to use a plan-driven approach. Is an incremental delivery strategy, where you deliver the software to customers and get rapid feedback from them, realistic? If so, consider using agile methods. How large is the system that is being developed? Agile methods are most effective when the system can be developed with a small co-located team who can communicate informally. This may not be possible for large systems that require larger development teams so a plan-driven approach may have to be used.

Technical, human, organizational issues What type of system is being developed? Plan-driven approaches may be required for systems that require a lot of analysis before implementation (e.g. real-time system with complex timing requirements). What is the expected system lifetime? Long-lifetime systems may require more design documentation to communicate the original intentions of the system developers to the support team.

Technical, human, organizational issues What technologies are available to support system development? Agile methods rely on good tools to keep track of an evolving design How is the development team organized? If the development team is distributed or if part of the development is being outsourced, then you may need to develop design documents to communicate across the development teams.

When to Use Traditional SDLC Systems have been developed and documented using SLDC. It is important to document each step. Upper level management feels more comfortable or safe using SDLC. There are adequate resources and time to complete the full SDLC. Communication of how new systems work is important.

When to Use Agile There is a project support of agile methods in the organization. Applications need to be developed quickly in response to a dynamic environment. A rescue takes place (the system failed and there is no time to figure out what went wrong). The customer is satisfied with incremental improvements. Executives and analysts agree with the principles of agile methodologies.

Large systems development Large systems are usually collections of separate, communicating systems, where separate teams develop each system. Frequently, these teams are working in different places, sometimes in different time zones. Large systems are ‘brownfield systems’, that is they include and interact with a number of existing systems. Many of the system requirements are concerned with this interaction and so don’t really lend themselves to flexibility and incremental development. Where several systems are integrated to create a system, a significant fraction of the development is concerned with system configuration rather than original code development.

Some part of the slide based on the Chapter 2 of Texbook Software Engineering , Sommerville . Some part of the slide based on the Chapter 2 of Textbook Systems Analysis and Design in a Changing World Chapter 1 Introduction

What about your project? Think about: Which approach is more relevant and effective for your project? Why? Form a realistic project group for your project? Which skills are required? Define your project as a business problem and define your projec’ scope How you implement iterative development approach to your project How you implement incremental development approach to your project?