Modern Approach to Systems Analysis and Design in Software Engineering
This lecture covers various topics in software engineering, including system analysis and design, software process models, system development life cycle, coping with change, and process improvement. It discusses the software process, process activities, software process models, and software process descriptions. The evolution of systems analysis and design from the 1950s to the present day is explored, highlighting key advancements and approaches in the field.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
CSE305 Software Engineering Lecture #2 Prepared & Presented byAsst. Prof. Dr. Samsun M. BA ARICI
Topics covered System analysis and design Software process and software process models System development life cycle Process activities Coping with change Process improvement 2
The software process A structured set of activities required to develop a software system. Many different software processes but all involve: Specification defining what the system should do; Design and implementation defining the organization of the system and implementing the system; Validation checking that it does what the customer wants; Evolution changing the system in response to changing customer needs. A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective. 3
Software process descriptions When we describe and discuss processes, we usually talk about the activities in these processes such as specifying a data model, designing a user interface, etc. and the ordering of these activities. Process descriptions may also include: Products, which are the outcomes of a process activity; Roles, which reflect the responsibilities of the people involved in the process; Pre- and post-conditions, which are statements that are true before and after a process activity has been enacted or a product produced. 4
A Modern Approach to Systems Analysis and Design 1950s: focus on efficient automation of existing processes 1960s: advent of 3GL, faster and more reliable computers 1970s: system development becomes more like an engineering discipline 5
A Modern Approach to Systems Analysis and Design (Cont.) 1980s: major breakthrough with 4GL, CASE tools, object oriented methods 1990s: focus on system integration, GUI applications, client/server platforms, Internet The new century: Web application development, wireless PDAs, component-based applications 6
A Modern Approach to Systems Analysis and Design (Cont.) Application Software Computer software designed to support organizational functions or processes Systems Analyst Organizational role most responsible for analysis and design of information systems 7
Plan-driven and agile processes Plan-driven processes are processes where all of the process activities are planned in advance and progress is measured against this plan. In agile processes, planning is incremental and it is easier to change the process to reflect changing customer requirements. In practice, most practical processes include elements of both plan-driven and agile approaches. There are no right or wrong software processes. 8
Systems Development Life Cycle (SDLC) Traditional methodology used to develop, maintain, and replace information systems. Phases in SDLC: Planning Analysis Design Implementation Maintenance 10
Software process models The waterfall model Plan-driven model. Separate and distinct phases of specification and development. Incremental development Specification, development and validation are interleaved. May be plan-driven or agile. Integration and configuration The system is assembled from existing configurable components. May be plan-driven or agile. In practice, most large systems are developed using a process that incorporates elements from all of these models. 11
Standard and Evolutionary Views of SDLC Evolutionary model The systems development life cycle 12
Systems Development Life Cycle (SDLC) (Cont.) Planning an organization s total information system needs are identified, analyzed, prioritized, and arranged Analysis system requirements are studied and structured 13
Systems Development Life Cycle (SDLC) (Cont.) Design a description of the recommended solution is converted into logical and then physical system specifications Logical design all functional features of the system chosen for development in analysis are described independently of any computer platform 14
Systems Development Life Cycle (SDLC) (Cont.) Physical design the logical specifications of the system from logical design are transformed into the technology- specific details from which all programming and system construction can be accomplished 15
Systems Development Life Cycle (SDLC) (Cont.) Implementation the information system is coded, tested, installed and supported in the organization Maintenance an information system is systematically repaired and improved 16
The Heart of the Systems Development Process The analysis design code test loop The heart of systems development Current practice combines analysis, design, and implementation into a single iterative and parallel process of activities.
Traditional Waterfall SDLC One phase begins when another completes, with little backtracking and looping. A traditional waterfall SDLC 19
Waterfall model phases There are separate identified phases in the waterfall model: Requirements analysis and definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance The main drawback of the waterfall model is the difficulty of accommodating change after the process is underway. In principle, a phase has to be complete before moving onto the next phase. 21
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. 22
Different Approaches to Improving Development CASE Tools Rapid Application Development (RAD) Agile Methodologies eXtreme Programming 23
Computer-Aided Software Engineering (CASE) Tools Diagramming tools enable graphical representation. Computer displays and report generators help prototype how systems look and feel . 24
Computer-Aided Software Engineering (CASE) Tools (Cont.) Analysis tools automatically check for consistency in diagrams, forms, and reports. A central repository provides integrated storage of diagrams, reports, and project management specifications. 25
Computer-Aided Software Engineering (CASE) Tools (Cont.) Documentation generators standardize technical and user documentation. Code generators enable automatic generation of programs and database code directly from design documents, diagrams, forms, and reports. 26
Computer-Aided Software Engineering (CASE) Tools (Cont.) A class diagram from IBM s Rational Rose (Source: IBM) 27
Rapid Application Development (RAD) Methodology to radically decrease design and implementation time Involves: extensive user involvement, prototyping, JAD sessions, integrated CASE tools, and code generators 29
Rapid Application Development (RAD) (Cont.) RAD life cycle 30
Service-Oriented Architecture (SOA) An approach to systems development based on building complete systems through assembling software components, each of which model generic business functions 31
Service-Oriented Architecture (SOA) (Cont.) Illustration of a service, a credit check, used by applications and other services 32
Agile Methodologies Motivated by recognition of software development as fluid, unpredictable, and dynamic Three key principles Adaptive rather than predictive Emphasize people rather than roles Self-adaptive processes 33
The Agile Methodologies group argues that software development methodologies adapted from engineering generally do not fit with real- world software development. 34
When to use Agile Methodologies If your project involves: Unpredictable or dynamic requirements Responsible and motivated developers Customers who understand the process and will get involved 35
eXtreme Programming Short, incremental development cycles Automated tests Two-person programming teams 37
eXtreme Programming (Cont.) Coding and testing operate together Advantages: Communication between developers High level of productivity High-quality code 38
Object-Oriented Analysis and Design (OOAD) Based on objects rather than data or processes Object: a structure encapsulating attributes and behaviors of a real-world entity 39
Object-Oriented Analysis and Design (OOAD) (Cont.) Object class: a logical grouping of objects sharing the same attributes and behaviors Inheritance: hierarchical arrangement of classes enable subclasses to inherit properties of superclasses 40
Rational Unified Process (RUP) An object-oriented systems development methodology RUP establishes four phase of development: inception, elaboration, construction, and transition. Each phase is organized into a number of separate iterations. 41
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. 43
Incremental development problems The process is not visible. Managers need regular deliverables to measure progress. If systems are developed quickly, it is not cost-effective to produce documents that reflect every version of the system. System structure tends to degrade as new increments are added. Unless time and money is spent on refactoring to improve the software, regular change tends to corrupt its structure. Incorporating further software changes becomes increasingly difficult and costly. 44
Integration and configuration Based on software reuse where systems are integrated from existing components or application systems (sometimes called COTS -Commercial-off-the-shelf) systems). Reused elements may be configured to adapt their behaviour and functionality to a user s requirements Reuse is now the standard approach for building many types of business system Reuse covered in more depth in Chapter 15. 45
Types of reusable software Stand-alone application systems (sometimes called COTS) that are configured for use in a particular environment. Collections of objects that are developed as a package to be integrated with a component framework such as .NET or J2EE. Web services that are developed according to service standards and which are available for remote invocation. 46
Key process stages Requirements specification Software discovery and evaluation Requirements refinement Application system configuration Component adaptation and integration 48
Advantages and disadvantages Reduced costs and risks as less software is developed from scratch Faster delivery and deployment of system But requirements compromises are inevitable so system may not meet real needs of users Loss of control over evolution of reused system elements 49
