Chapter 1 (RASD 3/e) MACIASZEK, L.A. (2007): Requirements Analysis and System Design, 3 rd ed. Addison Wesley, Harlow England ISBN 978-0-321-44036-5 Chapter 1 Software Process Pearson Education Limited 2007 Topics The nature of software development System planning Systems for three management levels The software development lifecycle Development models and methods Problem statements for case studies (separate set of slides) Chapter 1 (Maciaszek - RASD 3/e) 2 MACIASZEK (2007): Req Analysis & Syst Design 1
Chapter 1 (RASD 3/e) 1. The nature of software development 70% of software projects fail (The Standish Group report, 2005) an exaggeration? The essence of software development defined by the issues inherent in the software itself software is a product of a creative act (not a result of a repetitive act of manufacturing) difficulties not amenable to breakthroughs or silver bullets software development invariants (constants): complexity, conformity, changeability, and invisibility. Chapter 1 (Maciaszek - RASD 3/e) 4 MACIASZEK (2007): Req Analysis & Syst Design 2
Chapter 1 (RASD 3/e) The accidents of software development Accidental difficulties (variables) due to software production practices amenable to human intervention attributed mostly to the fact that an information system is a social system the software solution must not be adding to the inherent complexity of the software product adaptiveness (supportability) is the challenge Related to: adaptiveness = understandability + maintainability + scalability (extensibility) Stakeholders Process Modeling Chapter 1 (Maciaszek - RASD 3/e) 5 Variable 1 - Stakeholders People who have a stake in a software project: Customers (users and system owners) Developers (analysts, designers, programmers, etc.) Information systems are social systems developed by people (developers) for people (customers) The main causes of software failure can be traced to the stakeholder factor on the customer end, and on the developer end Chapter 1 (Maciaszek - RASD 3/e) 6 MACIASZEK (2007): Req Analysis & Syst Design 3
Chapter 1 (RASD 3/e) Variable 2 - Software process Defines activities and organizational procedures used in software production and maintenance A process model: states an order for carrying out activities; specifies what development artifacts are to be delivered and when; assigns activities and artifacts to developers; offers criteria for monitoring a project s progress, for measuring the outcomes, and for planning future projects. Is not susceptible to standardization Chapter 1 (Maciaszek - RASD 3/e) 7 Iterative and incremental process An iterative process is one that involves managing a stream of executable releases. An incremental process is one that involves the continuous integration of the system s architecture to produce these releases, with each new release embodying incremental improvements over the other. (RUP) Some examples: the spiral model the Rational Unified Process (RUP) Model Driven Architecture (MDA) the agile development process aspect-oriented software development Iterative and incremental development must be planned and controlled, and must conform to a pre-defined architectural design framework (meta-architecture) Chapter 1 (Maciaszek - RASD 3/e) 8 MACIASZEK (2007): Req Analysis & Syst Design 4
Chapter 1 (RASD 3/e) Capability maturity model Improve process discipline Level 1 Initial Improve process definition Level 2 Repeatable Improve process control Unpredictable and undisciplined process that depends on the current staff. Level 3 Defined Improve process itself Level 4 Managed Metrics used to control the process. Both management and engineering processes are codified and followed. Repeatable project management; consistent time and effort predictions for similar projects. Level 5 Optimizing Continuous process improvement in place. Chapter 1 (Maciaszek - RASD 3/e) 9 ISO 9000 family of quality standards Developed by the International Organization for Standardization The ISO standards apply to the quality management and the process to produce a quality product apply to any industry and all types of businesses, including software development The main premise if the process is right then the process outcome (product or service) will also be right but... the ISO standards do not enforce or specify processes the standards provide models of what must be accomplished, not how activities must be performed Chapter 1 (Maciaszek - RASD 3/e) 10 MACIASZEK (2007): Req Analysis & Syst Design 5
Chapter 1 (RASD 3/e) ITIL framework IT as commodity Software becomes merely a service enabling business solution solution (service) delivery IT Infrastructure Library (ITIL) the most widely used and accepted framework of best practices for IT service management Efficient and effective use of the four Ps people, processes, products (tools and technology) and partners (suppliers, vendors and outsourcing organizations). Next slide - solution management as a Continuous Service Improvement Programme (CSIP) Chapter 1 (Maciaszek - RASD 3/e) 11 CSIP What is the vision? High level business objectives Where are we now? Maturity assessment How do we keep the momentum going? Where do we want to be? Measurable targets How do we get where we want to be? Process improvement plan How do we check milestones have been reached? Measurements and metrics Chapter 1 (Maciaszek - RASD 3/e) 12 MACIASZEK (2007): Req Analysis & Syst Design 6
Chapter 1 (RASD 3/e) COBIT framework ITIL addresses the operational side of the solution delivery and management ITIL, CMM and ISO 9000 are process standards COBIT (Control OBjectives for Information and related Technology) is a compliance framework and addresses the control side of the solution management COBIT is rather a product standard COBIT groups IT-related efforts into four domains: Plan and Organize, Acquire and Implement, Deliver and Support, and Monitor. The domains are assigned control objectives 34 high-level control objectives 318 recommended detailed control objectives Chapter 1 (Maciaszek - RASD 3/e) 13 Variable 3 - Modeling Modeling artifacts have to be communicated (language) and documented (tools) The Unified Modeling Language (UML) is a generalpurpose visual modeling language that is used to specify, visualize, construct, and document the artifacts of a software system. Computer-Assisted Software Engineering (CASE) tool enables storage and retrieval of models in a central repository and graphical and textual manipulation of models on a computer screen Chapter 1 (Maciaszek - RASD 3/e) 14 MACIASZEK (2007): Req Analysis & Syst Design 7
Chapter 1 (RASD 3/e) UML UML is independent of any software development process A process that adopts UML must support an object-oriented oriented approach to software production implementation technologies (as long as they are objectoriented) This makes UML somewhat deficient in supporting the detailed design phase of the development lifecycle The UML models can be categorized into three groups: State models describe the static data structures Behavior models describe object collaborations State change models describe the allowed states for the system over time Chapter 1 (Maciaszek - RASD 3/e) 15 CASE and process improvement Process improvement is much more than the introduction of new tools, methods and techniques the introduction of new methods and techniques to organization at a low level of process maturity can bring more harm than good An integrated CASE tool can allow multiple developers to collaborate and share design information in order to produce new design artifacts the tool imposes processes on the development team in immature organizations processes will not be followed (creating more mess than before) However, a CASE tool would always bring personal productivity and quality improvements to individual developers Chapter 1 (Maciaszek - RASD 3/e) 16 MACIASZEK (2007): Req Analysis & Syst Design 8
Chapter 1 (RASD 3/e) Development or integration? Application development Stand-alone From-scratch Integration development Value-added or Brand new application that (also) requires integration of existing apps Integration approaches Information- and/or portal-oriented Interface-oriented Process-oriented Chapter 1 (Maciaszek - RASD 3/e) 17 Review Quiz 1.1 1. Do accidents of software development define the software development invariants? 2. What are the two main groups of stakeholders in software projects? 3. Does each incremental release within an iteration add a new functionality to the software product under development? 4. Is COBIT a product or a process standard? 5. Is portal-oriented integration a special kind of interface-oriented integration? Chapter 1 (Maciaszek - RASD 3/e) 18 MACIASZEK (2007): Req Analysis & Syst Design 9
Chapter 1 (RASD 3/e) 2. System planning Which IS technologies and applications will return the most value to the business? System planning System planning can be carried out in a number of different ways: SWOT Strengths, Weaknesses, Opportunities, Threats VCM Value Chain Model BPR Business Process Reengineering Information System Architecture (ISA) All system planning approaches have an important common denominator they are concerned with effectiveness rather than efficiency Chapter 1 (Maciaszek - RASD 3/e) 20 MACIASZEK (2007): Req Analysis & Syst Design 10
Chapter 1 (RASD 3/e) SWOT approach Mission statement Internal analysis External analysis Strengths Weaknesses Opportunities Threats SWOT matrix Objectives Goals Strategies Policies Chapter 1 (Maciaszek - RASD 3/e) 21 VCM approach The VCM (Value Chain Model) assesses competitive advantage by analyzing the full chain of activities in an organization from raw materials to final products sold and shipped to customers The question is: which value chain configurations will yield the greatest competitive advantage? The IS development projects can then target those segments, operations, distribution channels, marketing approaches, etc. that give the most competitive advantage Organizational functions are categorized into: primary activities they create or add value to a final product support activities they are essential but they do not enrich the product Chapter 1 (Maciaszek - RASD 3/e) 22 MACIASZEK (2007): Req Analysis & Syst Design 11
Chapter 1 (RASD 3/e) BPR approach The BPR (Business Process Reengineering) approach to system planning is based on the premise that today s organizations must reinvent themselves and abandon the functional decomposition, hierarchical structures and operational principles that they are now using Most contemporary organizations are structured in vertical units focused on functions, products or regions No one employee or department is responsible for a business process which is defined as... a collection of activities that takes one or more kinds of input and creates an output that is of value to the customer The most visible difference between a process enterprise and a traditional organization is the existence of process owners The main objective of BPR is to radically redesign business processes in an organization (hence, process redesign) The major hurdle lies in the need to embed a horizontal process in a traditional vertical management structure BPR initiative requires changing the organization around the development teams as the primary organizational units These teams are responsible for one or more end-to to-end business processes Chapter 1 (Maciaszek - RASD 3/e) 23 ISA approach ISA (Information Systems Architecture) is a bottom-up approach that offers a neutral architectural framework for IS solutions that can suit a variety of business strategies it does not include a system planning methodology it offers a framework that leverages most business strategies The ISA framework is represented as a table of thirty cells organized into five rows (labeled 1 through 5) and six columns (labeled A through F) Rows represent the different perspectives used in the construction of a complex engineering product, such as an information system five major players in the game Columns represent the six different descriptions or architectural models that each of the participants engages with Chapter 1 (Maciaszek - RASD 3/e) 24 MACIASZEK (2007): Req Analysis & Syst Design 12
Chapter 1 (RASD 3/e) Review Quiz 1.2 1. What is the main target of system planning effectiveness or efficiency? 2. In the SWOT analysis, are objectives derived from goals or vice versa? 3. In the VCM approach, is sales and marketing a primary or support activity? 4. According to the BPR approach, what is the most visible difference between a process enterprise and a traditional organization? 5. What are the five perspectives of the ISA framework? Chapter 1 (Maciaszek - RASD 3/e) 25 3. Systems for three management levels strategic tactical operational MACIASZEK (2007): Req Analysis & Syst Design 13
Chapter 1 (RASD 3/e) Systems for three management levels Level of decision making Focus of decision making Typical IS applications Typical IT solutions Pivotal concept Strategic (executive and senior management levels) Strategies in support of organizational long-term objectives Market and sales analysis, Product planning, Performance evaluation Data mining, Knowledge management Knowledge Tactical (line management level) Policies in support of shortterm goals and resource allocation Budget analysis, Salary forecasting, Inventory scheduling, Customer service Data warehouse, Analytical processing, Spreadsheets Information Operational (operative management level) Day-to-day staff activities and production support Payroll, Invoicing, Purchasing, Accounting Database, Transactional processing, Application generators Data Chapter 1 (Maciaszek - RASD 3/e) 27 Transactional processing systems OnLine Transaction Processing (OLTP) systems Transaction a logical unit of work that accomplishes a particular business task and guarantees the integrity of the database after the task completes Database technology Concurrency control Recovery Business logic (vs( application/control logic) Security Chapter 1 (Maciaszek - RASD 3/e) 28 MACIASZEK (2007): Req Analysis & Syst Design 14
Chapter 1 (RASD 3/e) Analytical processing systems OnLine Analytical Processing (OLAP) systems Analysis of pre-existing historical data to facilitate decision making Data warehouse technology Summarizing Packaging Partitioning Data marts Data webhouse Chapter 1 (Maciaszek - RASD 3/e) 29 Knowledge processing systems Know-how intellectual capital accumulated through experience Knowledge management to help organizations discover, organize, distribute and apply the knowledge encoded in information systems Data mining Association Classification Clustering AI techniques predictive rather than retrospective models Chapter 1 (Maciaszek - RASD 3/e) 30 MACIASZEK (2007): Req Analysis & Syst Design 15
Chapter 1 (RASD 3/e) Review Quiz 1.3 1. Which level of decision making is primarily supported by the data warehouse technology? 2. What are the two main functions of transaction management in OLTP systems? 3. What kind of OLAP technology aims at supporting individual departments or business functions and stores only summarized historical data? 4. What is the main technology underpinning knowledge processing systems? Chapter 1 (Maciaszek - RASD 3/e) 31 4. The software development lifecycle strategic tactical operational MACIASZEK (2007): Req Analysis & Syst Design 16
Chapter 1 (RASD 3/e) Software development lifecycle The lifecycle identifies: the applied modeling approach the exact phases along which the software product is transformed from initial inception to phasing it out the method (methodology) and associated development process Chapter 1 (Maciaszek - RASD 3/e) 33 Development approach Software has become much more interactive event-driven user in control software objects service random and unpredictable events Conventional software has been well served by the so-called structured approach Modern interactive GUI systems require object programming and the object approach is the best way to design such systems Chapter 1 (Maciaszek - RASD 3/e) 34 MACIASZEK (2007): Req Analysis & Syst Design 17
Chapter 1 (RASD 3/e) Structured approach Popularized in 1980s Based on: DFD (data flow diagrams) for process modeling ERD (entity relationship diagrams) for data modeling Process-centric Brakes system down to manageable units in the activity called functional decomposition Not well aligned with modern software engineering: sequential and transformational approach rather than iterative and incremental tends to deliver inflexible solutions that satisfy the set of identified business functions assumes development from scratch, and it does not support the reuse of pre-existing components Chapter 1 (Maciaszek - RASD 3/e) 35 Object-oriented approach Popular since 1990s Data-centric it evolves around class models But the growing significance of use cases in UML shifts the emphasis slightly from data to processes Matches the event-driven programming demanded by interactive GUI-based applications Addresses the needs of emerging applications, such as workgroup computing and multimedia systems Good at fighting application backlogs using object wrapping and similar techniques Aligns with the iterative and incremental process Chapter 1 (Maciaszek - RASD 3/e) 36 MACIASZEK (2007): Req Analysis & Syst Design 18
Chapter 1 (RASD 3/e) Problems related to OO development The semantic gap between the object-oriented modeling artifacts and the implementation of the data-centric artifacts with relational database technology can be significant Project management is more difficult In object-oriented development through elaboration there are no clear boundaries between phases, and project documentation evolves continuously Object solutions are significantly more complex than old-style structured systems The complexity results from the need for extensive interobject communication ( complexity in the wires ) Good architectural design a necessity Chapter 1 (Maciaszek - RASD 3/e) 37 Lifecycle phases Business Analysis functional and non-functional requirements System Design architectural design detailed design Implementation coding round-trip engineering Integration and Deployment Operation and Maintenance Chapter 1 (Maciaszek - RASD 3/e) 38 MACIASZEK (2007): Req Analysis & Syst Design 19
Chapter 1 (RASD 3/e) Business analysis Also requirements analysis Activity of determining and specifying customer requirements business analyst determines requirements system analyst specifies (or models) requirements Business analysis is linked to business process reengineering (BPR) aim of BPR is to propose new ways of conducting business and gaining competitive advantage Business analysis becomes increasingly an act of requirements engineering Chapter 1 (Maciaszek - RASD 3/e) 39 Requirements determination Requirement a statement of a system service or constraint Service statement a business rule that must be obeyed at all times (e.g. fortnightly salaries are paid on Wednesdays ) a computation that the system must carry out (e.g. calculate salesperson commission based on the sales in the last fortnight using a particular formula ) Constraint statement a restriction on the system s behavior ( only direct managers can see the salary information of their staff ) a restriction on the system s development ( we must use Sybase development tools ) Chapter 1 (Maciaszek - RASD 3/e) 40 MACIASZEK (2007): Req Analysis & Syst Design 20
Chapter 1 (RASD 3/e) Requirements specification Begins when the developers start modeling the requirements using a particular method (such as UML) CASE tool is used to enter, analyze and document the models Requirements Document is enriched with graphical models and CASE-generated reports Specifications document (the specs in the jargon) replaces the requirements document Most important specification techniques class diagrams use case diagrams Ideally, the specification models should be independent from the hardware/software platform on which the system is to be deployed Chapter 1 (Maciaszek - RASD 3/e) 41 Architectural design The description of the system in terms of its modules (components) Concerned with selection of a solution strategy to resolve client (user interface) and server (database) issues as well as any middleware needed to glue client and server processes modularization of the system relatively independent from a solution strategy but the detailed design of components must conform to a selected client/server solution Client/server models are frequently extended to provide a three-tier architecture where application logic constitutes a separate layer Good architectural design produces adaptive (supportable) systems, i.e. systems that are understandable, maintainable, and scalable (extensible) Chapter 1 (Maciaszek - RASD 3/e) 42 MACIASZEK (2007): Req Analysis & Syst Design 21
Chapter 1 (RASD 3/e) Detailed design Description of the internal workings of each software component Develops detailed algorithms and data structures for each component Dependent on the underlying implementation platform client server middleware Chapter 1 (Maciaszek - RASD 3/e) 43 Implementation Involves installation of purchased software coding of custom-written software other important activities, such as loading of test and production databases, testing, user training, hardware issues, etc. Client programs Server programs Chapter 1 (Maciaszek - RASD 3/e) 44 MACIASZEK (2007): Req Analysis & Syst Design 22
Chapter 1 (RASD 3/e) Integration and deployment Module integration can take more time and effort than any one of the earlier lifecycle phases, including implementation The whole is more than the sum of the parts (Aristotle) must be carefully planned from the very beginning of the software lifecycle Application integration integrating disparate (stovepipe) applications into a unified enterprise application through which all data and processes are shared Deployment must be carefully managed and allow, if at all possible, fallback to the old solution, if problems encountered Chapter 1 (Maciaszek - RASD 3/e) 45 Operation and maintenance Operation signifies change over from the existing business solution, whether in software or not Maintenance is not only an inherent part of the software lifecycle it accounts for most of it as far as IT personnel time and effort is concerned Housekeeping Adaptive maintenance Perfective maintenance Phasing out would normally happen due to reasons that have little to do with the usefulness of the software Chapter 1 (Maciaszek - RASD 3/e) 46 MACIASZEK (2007): Req Analysis & Syst Design 23
Chapter 1 (RASD 3/e) Activities spanning the lifecycle Project planning Metrics Testing Chapter 1 (Maciaszek - RASD 3/e) 47 Project planning If you can t plan it, you can t do it Activity of estimating the project s deliverables, costs, time, risks, milestones, and resource requirements Includes the selection of development methods, processes, tools, standards, team organization, etc. A moving target Typical constraints are time and money Chapter 1 (Maciaszek - RASD 3/e) 48 MACIASZEK (2007): Req Analysis & Syst Design 24
Chapter 1 (RASD 3/e) Metrics Measuring development time and effort Without measuring the past, the organization is not able to plan accurately for the future Metrics are usually discussed in the context of software quality and complexity they apply to the quality and complexity of the software product Equally important application of metrics is measuring the development models (development products) at different phases of the lifecycle to assess the effectiveness of the process and to improve the quality of work at various lifecycle phases Chapter 1 (Maciaszek - RASD 3/e) 49 Testing Test cases should be defined for each functional module (use case) described in the requirements document Desktop testing by developers not sufficient Methodical testing by Software Quality Assurance (SQA) group necessary Requirements, specifications and any documents (including program source code) can be tested in formal reviews (so-called walkthroughs and inspections) Execution-based testing: Testing to specs (black-box testing) Testing to code (white-box or glass-box testing) Chapter 1 (Maciaszek - RASD 3/e) 50 MACIASZEK (2007): Req Analysis & Syst Design 25
Chapter 1 (RASD 3/e) Review Quiz 1.4 1. Which software development approach, structured or object-oriented, takes advantage of the activity of functional decomposition? 2. What is another name for business analysis? 3. Which development phase is largely responsible for producing/delivering an adaptive system? 4. The notion of a stub is associated with what development phase? 5. Which activities span the development lifecycle and are not, therefore, distinct lifecycle phases? Chapter 1 (Maciaszek - RASD 3/e) 51 5. Development models and methods how of software production called also lifecycle models MACIASZEK (2007): Req Analysis & Syst Design 26
Chapter 1 (RASD 3/e) Development models Model defines an approach to software production Has an associated process iterative and incremental Process is unique (different) for each organization Representative models for iterative and incremental development: the spiral model the IBM Rational Unified Process (RUP) Model Driven Architecture (MDA) agile software development aspect-oriented development Chapter 1 (Maciaszek - RASD 3/e) 53 Spiral model Project cost Planning Risk analysis go, no-go decision Project progress Customer evaluation Engineering Chapter 1 (Maciaszek - RASD 3/e) 54 MACIASZEK (2007): Req Analysis & Syst Design 27
Chapter 1 (RASD 3/e) IBM Rational Unified Process (RUP) Requirements Analysis & Design Business Modeling Management Environment Configuration Management Deployment Start of the process Implementation Test RUP organizes projects in twodimensional terms The horizontal dimension represents the successive phases of each project iteration: inception, elaboration, construction, and transition. The vertical dimension represents seven software development disciplines and supporting activities of configuration and change management, project management, and environment. Chapter 1 (Maciaszek - RASD 3/e) 55 Model Driven Architecture (MDA) Customer requirements Mostly text Analysis Platform Independent Model Design Coding Applicable standards: Unified Modeling Language (UML) Meta-Object Facility (MOF) for using a Platform Specific Model Code PSM bridge Code bridge Platform Specific Model Code standard meta-model repository so that derived specifications can work together XML Meta-Data Interchange (XMI) for mapping UML to XML for interchange purposes, Common Warehouse Meta-model (CWM) for mapping of MDA to database schemas and permitting flexible data mining. Chapter 1 (Maciaszek - RASD 3/e) 56 MACIASZEK (2007): Req Analysis & Syst Design 28
Chapter 1 (RASD 3/e) Agile software development Key points of agility in software production: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan The best known representatives: extreme Programming (XP) Aspect Oriented Software Development Feature-Driven Development Lean Development Acceptance tests Test-driven development User stories Refactoring Continuous integration Chapter 1 (Maciaszek - RASD 3/e) 57 Aspect-oriented software development Produces more modular systems by identifying so called crosscutting concerns Typically, nonfunctional requirements/qualities The modules are called aspects Base code vs aspect code The aspects are integrated through the process called aspect weaving Static vs dynamic weaving Applies to join points in a program s execution A particular action that needs to be taken for a join point is called an advice Aspects Aspect weaving Crosscutting concerns Join points Advice Chapter 1 (Maciaszek - RASD 3/e) 58 MACIASZEK (2007): Req Analysis & Syst Design 29
Chapter 1 (RASD 3/e) Review Quiz 1.5 1. Is adding a new functionality to a software project the responsibility of a software iteration or integration? 2. Which of the development models/methods is most explicit about risk analysis? 3. Which development model/method is directly linked to the traditional concept of formal specifications? 4. Which development model/method is directly linked to the concept of intentional programming? 5. Which development model/method is directly linked to the concept of crosscutting concerns? Chapter 1 (Maciaszek - RASD 3/e) 59 Case studies (separate set of slides) University Enrolment (UE) Video Store (VS) Contact Management (CM) Telemarketing (TM) Advertising Expenditure (AE) Time Logging (TL) Currency Converter (CC) Chapter 1 (Maciaszek - RASD 3/e) 60 MACIASZEK (2007): Req Analysis & Syst Design 30
Chapter 1 (RASD 3/e) Summary The nature of software development is that of a craft or even art. The triangle for success includes the stakeholders factor, a sound process and the support of a modeling language and tools. System planning precedes software development and determines which products can be most effective to the organization. Modern software products are object-oriented. Software development follows a lifecycle. Modern development lifecycles and processes are iterative and incremental. Chapter 1 (Maciaszek - RASD 3/e) 61 MACIASZEK (2007): Req Analysis & Syst Design 31