Software Engineering G22.

Session 1 - Main Theme Software Engineering Fundamentals
Dr. Jean-Claude Franchitti

New York University Computer Science Department Courant Institute of Mathematical Sciences



Course Overview and Logistics Software Engineering Scope Software Engineering Discipline Software Development Challenges Refining the Software Engineering Discipline The Human Side of Software Development Software Engineering Best Practices ala Rational Rational Unified Process (RUP) Introduction to Agile Software Engineering Summary

Course Assignments Course Project Readings

Session Objectives

Define software engineering and explain its importance Discuss the concepts of software products and software processes Explain the importance of process visibility Introduce the notion of professional responsibility Introduce Agile Software Engineering

Part I
Course Overview and Logistics


Course Logistics

Course Web Site Login/Password (not currently protected) Review syllabus Software Engineering: A Practitioner's Approach with Bonus Chapter on Agile Development Roger S. Pressman McGraw-Hill Science/Engineering/Math ISBN: 0072989572, 5th Edition (12/03)


Useful Knowledge

Business Process Modeling (BPML) Object-Oriented Analysis and Design (OOAD) Object-oriented technology experience Software development experience as a software development team member in the role of business analyst, developer, or project manager Implementation language experience (e.g., C++, Java) Note: Knowledge of UML or a specific programming language is not required


Course Objectives

Present modern software engineering techniques and examines the software life-cycle, including software specification, design implementation, testing and maintenance

Describe and compare various software development methods and understand the context in which each approach might be applicable

Develop students’ critical skills to distinguish sound development practices from ad hoc practices, judge which technique would be most appropriate for solving large-scale software problems, and articulate the benefits of applying sound practices

Course Objectives (continued)

Expand students’ familiarity with mainstream languages used to model and analyze processes and object designs (e.g., BPML, UML).

Demonstrate the importance of formal/executable specifications of object models, and the ability to verify the correctness/completeness of solution by executing the models.

Explain the scope of the software maintenance problem and demonstrate the use of several tools for reverse engineering software.

Course Objectives (continued)

Develop students’ ability to evaluate the effectiveness of an organization’s SW development practices, suggest improvements, and define a process improvement strategy

Introduce state-of-the-art tools and techniques for large-scale development Implement the major software development methods in practical projects and motivate discussion via group presentations


Software Requirements

Microsoft Windows 2000 / 2003 / XP Professional Software tools will be available from the Internet or from the course Web site under demos as a choice of freeware or commercial tools

Business and Application Modeling Tools Software Development Tools Workflow Management Frameworks etc.

References will be provided on the course Web site

GNP per capita is the dollar value of a country’s final output of goods and services in a year. . It reflects the 12 average income of a country’s citizens.Part II Software Engineering Scope 11 Software Engineering The economies of ALL developed nations are dependent on software More and more systems are software controlled Software engineering is concerned with theories. divided by its population. methods and tools for professional software development Software engineering expenditure represents a significant fraction of GNP in all developed countries GNP stands for Gross National Product.

Software Costs Software costs often dominate system costs. For systems with a long life. The costs of software on a PC are often greater than the hardware cost Software costs more to maintain than it does to develop. maintenance costs may be several times development costs Software engineering is concerned with cost-effective software development 13 Software Products Generic products Stand-alone systems which are produced by a development organization and sold on the open market to any customer Systems which are commissioned by a specific customer and developed specially by some contractor Bespoke (customized) products Most software expenditure is on generic products but most development effort is on bespoke systems 14 .

some attributes may dominate In safety-critical real-time systems. key attributes may be dependability and efficiency Costs tend to rise exponentially if very high levels of any one attribute are required 16 .Software Product Attributes Maintainability It should be possible for the software to evolve to meet changing requirements Dependability The software should not cause physical or economic damage in the event of failure Efficiency The software should not make wasteful use of system resources Usability Software should have an appropriate user interface and documentation 15 Importance of Product Characteristics The relative importance of these characteristics depends on the product and the environment in which it is to be used In some cases.

dependability.Efficiency Costs Cost Ef ficiency 17 Key Points Software engineering is concerned with the theories. Product attributes are maintainability. efficiency and usability 18 . methods and tools for developing. managing and evolving software products Software products consist of programs and documentation.

Part III Software Engineering Discipline 19 The Software Process Structured set of activities required to develop a software system Specification Design Validation Evolution Activities vary depending on the organization and the type of system being developed Must be explicitly modeled if it is to be managed 20 .

Process Characteristics Understandability Is the process defined and understandable? Is the process progress externally visible? Can the process be supported by CASE tools? Is the process acceptable to those involved in it? 21 Visibility Supportability Acceptability Process Characteristics Reliability Are process errors discovered before they result in product errors? Can the process continue in spite of unexpected problems? Can the process evolve to meet changing organizational needs? How fast can the system be produced? 22 Robustness Maintainability Rapidity .

specifications are incomplete/anomalous Very blurred distinction between specification.Produce a paper model of the system Manufacture .repair faults in the system as they are discovered 23 Software Process Models Normally.check if the system meets the required specifications Install .Engineering Process Model Specification .set out the requirements and constraints on the system Design .build the system Test .deliver the system to the customer and ensure it is operational Maintain .maintenance does not mean component replacement 24 . design and manufacturing No physical realization of the system for testing Software does not wear out .

Generic Software Process Models The waterfall model Separate and distinct phases of specification and development Specification and development are interleaved A mathematical system model is formally transformed to an implementation The system is assembled from existing components Evolutionary development Formal transformation Reuse-based development 25 Waterfall Model Requirements definition System and software design Implementation and unit testing Integr ation and system testing Operation and maintenance 26 .

Waterfall Model Phases Phases: Requirements analysis and definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance The drawback of the waterfall model is the difficulty of accommodating change after the process is underway 27 Evolutionary Development Concurr ent activities Specification Initial version Outline description Development Intermediate versions Validation Final version 28 .

g. languages for rapid prototyping) may be required For small or medium-size interactive systems For parts of large systems (e.Evolutionary Development Exploratory prototyping Objective is to work with customers and to evolve a final system from an initial outline specification Should start with well-understood requirements Objective is to understand the system requirements Should start with poorly understood requirements Throw-away prototyping 29 Evolutionary Development Problems Lack of process visibility Systems are often poorly structured Special skills (e. the user interface) For short-lifetime systems 30 Applicability .g..

Key Points The software process consists of those activities involved in software development The waterfall model considers each process activity as a discrete phase Evolutionary development considers process activities as concurrent 31 Part IV Software Development Challenges 32 .

Inherent Risks Sponsorship Budget Culture Business Understanding Priorities Business changes Features Schedule slips Methodology Misuse Software Quality 33 Symptoms of Software Development Problems User or business needs not met Requirements churn Modules don’t integrate Hard to maintain Late discovery of flaws Poor quality of end-user experience Poor performance under load No coordinated team effort Build-and-release issues 34 .

Trace Symptoms to Root Causes Symptoms Needs not met Requirements churn Modules don’t fit Hard to maintain Late discovery Poor quality Poor performance Colliding developers Build-and-release Root Causes Insufficient requirements Ambiguous communications Brittle architectures Overwhelming complexity Undetected inconsistencies Poor testing Subjective assessment Waterfall development Uncontrolled change Insufficient automation Best Practices Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change 35 Risk Management Perhaps the principal task of a manager is to minimize risk The 'risk' inherent in an activity is a measure of the uncertainty of the outcome of that activity High-risk activities cause schedule and cost overruns Risk is related to the amount and quality of available information. the higher the risk 36 . The less information.

Process Model Risk Problems Waterfall High risk for new systems because of specification and design problems Low risk for well-understood developments using familiar technology Low risk for new applications because specification and program stay in step High risk because of lack of process visibility High risk because of need for advanced technology and staff skills Prototyping Transformational 37 Part V Refining the Software Engineering Discipline 38 .

b en ch marks S/W requi rements Prod uct design Develop ment pl an Integration and test p lan Plan next p has e Code Unit tes t Integr ation test Accep tance test Develop. m odels.Hybrid Process Models Large systems are usually made up of several sub-systems The same process model need not be used for all subsystems Prototyping for high-risk specifications Waterfall model for well-understood developments 39 Spiral Model of the Software Process Determ ine ob jectiv es alternatives and cons traints Risk analys is Risk analys is Risk analys is Risk analysis Prototy pe 1 Concept o f Operation Prot otyp e 2 Prototyp e 3 Operati onal protoyp e Ev aluate altern atives id en tify. v erify Serv ice next-level p rod uct Design V& V Requi rement valid ation Detail ed desi gn 40 . resolve risk s REVIEW Requirement s plan Life-cycle pl an Sim ul ati ons.

Phases of the Spiral Model Objective setting Specific objectives for the project phase are identified Key risks are identified. analyzed and information is sought to reduce these risks An appropriate model is chosen for the next phase of development. The project is reviewed and plans drawn up for the next round of the spiral Risk assessment and reduction Development and validation Planning 41 Template for a Spiral Round Objectives Constraints Alternatives Risks Risk resolution Results Plans Commitment 42 .

Quality Improvement Objectives Significantly improve software quality Within a three-year timescale Without large-scale capital investment Without radical change to company standards Reuse existing certified software Introduce formal specification and verification Invest in testing and validation tools 43 Constraints Alternatives Risk Risks No cost effective quality improvement Possible quality improvements may increase costs excessively New methods might cause existing staff to leave Literature survey Pilot project Survey of potential reusable components Assessment of available tool support Staff training and motivation seminars 44 Risk resolution .

very hard to quantify improvements Limited tool support available for company-wide standard development system Reusable components available but little support exists in terms of reusability tools Explore reuse option in more detail Develop prototype reuse support tools Explore component certification scheme Fund further 18-month study phase Plans Commitment 45 Catalogue Spiral Objectives Procure software component catalogue Within a year Must support existing component types Total cost less than $100. 000 Buy existing information retrieval software Buy database and develop catalogue using database Develop special purpose catalogue 46 Constraints Alternatives .Approach Results Experience of formal methods is limited .

Risk Risks May be impossible to procure within constraints Catalogue functionality may be inappropriate Develop prototype catalogue (using existing 4GL and an existing DBMS) to clarify requirements Commission consultants report on existing information retrieval system capabilities. Identified requirements cannot be met. Prototype using DBMS may be enhanced to complete system Special purpose catalogue development is not costeffective Develop catalogue using existing DBMS by enhancing prototype and improving user interface Fund further 12 month development Plans Commitment 48 . Relax time constraint 47 Risk resolution Approach Results Information retrieval systems are inflexible.

Spiral Model Flexibility Hybrid models accommodated for different parts of a project: Well-understood systems (low technical risk) Use Waterfall model as risk analysis phase is relatively cheap Stable requirements and formal specification with safety criticality Use Formal transformation model Use Prototyping model 49 High UI risk with incomplete specification Spiral Model Advantages Focuses attention on reuse options Focuses attention on early error elimination Puts quality objectives up front Integrates development and maintenance Provides a framework for hardware/software development 50 .

this may cause problems Timing of progress deliverables may not match the time needed to complete an activity The need to produce documents constraints process iteration The time taken to review and approve documents is significant Waterfall model is still the most widely used deliverable-based model 52 .Spiral Model Problems Contractual development often specifies process model and deliverables in advance Requires risk assessment expertise Needs refinement for general use 51 Process Visibility Software systems are intangible so managers need documents to assess progress However.

Final user manual System test report Final system plus documentation 53 Process Model Visibility Process model Waterfall model Evolutionary development Formal transformations Reuse-oriented development Spiral model Process visibility Good visibility. Good visibility. Unit test plan Program code Unit test report Module test report Integration test report. Acceptance test plan Draft user manual Architectural specification. documents must be produced from each phase for the process to continue Moderate visibility. each segment and each ring of the spiral should produce some document. it may be artificial to produce documents describing reuse and reusable components. uneconomic to produce documents during rapid iteration Good visibility. Outline requirements Requirements document Functional specification. 54 . each activity produces some deliverable Poor visibility. Integration test plan Design specification.Waterfall Model Documents Activity Requirements analysis Requirements definition System specification Architectural design Interface design Detailed design Coding Unit testing Module testing Integration testing System testing Acceptance testing Output documents Feasibility study. System test plan Interface specification.

Key Points The spiral process model is risk-driven Process visibility involves the creation of deliverables from activities 55 Part VI The Human Side of Software Development 56 .

They have wider ethical.Professional Responsibility Software engineers should not just be concerned with technical considerations. social and professional responsibilities Not clear what is right or wrong about the following issues: Development of military systems Whistle blowing What is best for the software engineering profession 57 Ethical Issues Confidentiality Competence Intellectual property rights Computer misuse 58 .

Key Points Software engineers have ethical. social and professional responsibilities 59 Part VII Software Engineering Best Practices ala Rational 60 .

Section Outline Identify Steps for Understanding and Solving Software Engineering Problems Explain the Rational Six Best Practices Present the Rational Unified Process within the context of the Six Best Practices 61 Practice 1: Develop Iteratively Process Made Practical Best Practices Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change 62 .

Waterfall Development Characteristics Waterfall Process Requirements analysis Design Code and unit test Subsystem integration System test Delays confirmation of critical risk resolution Measures progress by assessing work-products that are poor predictors of time-to-completion Delays and aggregates integration and testing Precludes early deployment Frequently results in major unplanned iterations 63 Iterative Development Produces Executable Releases Requirements Analysis & Design Planning Initial Planning Implementation Management Environment Test Evaluation Each iteration results in an executable release Deployment 64 .

Risk Profiles Waterfall Risk Iterative Risk Risk Risk Reduction Time 65 Practice 2: Manage Requirements Process Made Practical Best Practices Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change 66 .

Requirements Management Making sure you Solve the right problem Build the right system eliciting organizing documenting managing By taking a systematic approach to the changing requirements of a software application. 67 Aspects of Requirements Management Analyze the Problem Understand User Needs Define the System Manage Scope Refine the System Definition Build the Right System 68 .

Map of the Territory Problem Needs Problem Space ity bil cea Tra Features Solution Space The Product To Be Built Use Cases and Software Requirements Test Procedures Design User Docs 69 Practice 3: Use Component Architectures Process Made Practical Best Practices Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change 70 .

Resilient. Component-Based Architectures Resilient Meets current and future requirements Improves extensibility Enables reuse Encapsulates system dependencies Component-based Reuse or customize components Select from commercially-available components Evolve existing software incrementally 71 Purpose of a Component-Based Architecture Basis for reuse Component reuse Architecture reuse Basis for project management Planning Staffing Delivery Component-based Architecture with layers Applicationspecific Businessspecific Middleware Systemsoftware 72 Intellectual control Manage complexity Maintain integrity .

Practice 4: Model Visually (UML) Process Made Practical Best Practices Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change 73 Why Model Visually? Capture structure and behavior Show how system elements fit together Keep design and implementation consistent Hide or expose details as appropriate Promote unambiguous communication UML: one language for all practitioners 74 .

EXE GraphicFile ÀÀ¿ë¼-¹ö. 6: fillDocument ( ) 7: readFile ( ) Target System 8: fillFile ( ) È-¸é °´Ã¼ ´Â ÀÐ ¾îµéÀÎ °´Ã¼µé¿¡ ´ëÇØ À̸§º°·Î Á¤·ÄÀ» ½ ÃÄÑ È.Visual Modeling with UML Static Diagrams Dynamic Diagrams Multiple views Precise syntax and semantics Use-Case Diagrams Class Diagrams Sequence Diagrams Object Diagrams Collaboration Diagrams Models Component Diagrams Statechart Diagrams Activity Diagrams Deployment Diagrams 75 Visual Modeling Using UML Diagrams Use-case diagram Use Case 1 Actor A Actor B Use Case 2 FileList fList add( ) delete( ) Class diagram DocumentList FileMgr add( ) delete( ) Document name : int docid : int numField : int get( ) open( ) close( ) read( ) sortFileList( ) create( ) fillDocument( ) fetchDoc( ) sortByName( ) Statechart diagram add file [ numberOffile==MAX ] / flag OFF read() fill the code.¸é¿¡ º¸¿©ÁØ´ Ù..¹ö repository : Repository mainWnd user fileMgr : FileMgr document : Document gFile repository ƯÁ¤¹® ¼-¿¡ ´ëÇÑ º¸±â¸¦ »ç¿ëÀÚ°¡ ¿äÃ»Ç Ñ´Ù.EXE ¹®¼-°ü¸® ¾ÖÇ Ã¸´ Wi ndows NT Solaris mainWnd : MainWnd FileManager Document 2: fetchDoc( ) 4: create ( ) 8: fillFile ( ) gFile : GrpFile user : Clerk fileMgr : FileMgr 3: create ( ) 6: fillDocument ( ) ¹®¼-°ü¸® ¿£Áø. 9: sortByN ame ( ) Sequence diagram 76 . 1: Doc view request ( ) 2: fetchDoc( ) Component diagram Forward and Reverse Engineering 3: create ( ) 4: create ( ) 5: readDoc ( ) È-ÀÏ°ü¸®ÀÚ´Â Àоî¿Â ¹®¼-ÀÇ Á¤º¸¸¦ ÇØ´ç ¹® ¼°´Ã¼¿¡ ¼ ³Á¤À» ¿äÃ»Ç Ñ´Ù. Openning add file Writing close file 1 close file Reading Use Case 3 Closing rep Repository (from Persistence) name : char * = 0 readDoc( ) readFile( ) read( ) open( ) create( ) fillFile( ) File read( ) GrpFile Collaboration diagram 1: Doc view request ( ) L 9: sortByName ( ) Repository DocumentList Deployment diagram Wi ndow95 Wi ndows95 Wi ndows95 ¹®¼-°ü¸® Ŭ¶óÀ̾ðÆ®.EXE Alpha UNIX File FileList Wi ndows NT 7: readFile ( ) 5: readDoc ( ) IBM Mainframe document : Document µ¥ÀÌŸº£À̽º¼.

UML Diagrams UML defines twelve types of diagrams.htm . divided into three categories Four diagram types represent static application structure: Class Diagram Object Diagram Component Diagram Deployment Diagram Use Case Diagram Sequence Diagram Activity Diagram Collaboration Diagram Statechart Diagram Five represent different aspects of dynamic behavior Three represent ways you can organize and manage your application modules Packages Subsystems Models 78 Source: http://www.UML Notation Baseline Diagram Name Use Case Class Activity State-Transition Event Trace (Interaction) Sequence Collaboration Package Deployment * ** Type Static* Static Dynamic** Dynamic Dynamic Dynamic Dynamic Static Dynamic Phase Analysis Analysis Analysis Analysis Design Design Design Delivery Delivery 77 Static describes structural system properties Dynamic describes behavioral system

1 p la y () 1 D ie fa ce V a lu e:in t=1 2 ro ll() 1 3: r2= roll( ) d2: D ie ligh t goes out P la ys 1 Po ur C offee D rin k Bev erage In clu d e s D ice G a m e 1 1 S corin g 1 H ig h S co re / S tart game Ready to play ca ncel M o m o: P lay er Play the game File S ystem Maybe a Remote a file system : DiceGame : Player d1 : Die d2 : Die 1: play( ) start Player ready e ntry: ge t player name 2: roll( ) 3: roll( ) Quit play roll dices[ turn<10 ] Cancel 80 [ turn>=10 ] In progress entry: turn++ .T u rnO n BrewC offee n a m e:S trin g sco re:in t=0 .UML Views Approach UML defines five views that let you look at overall models from various angles Layering architectural principles is used to allocate pieces of functionality to subsystems Partitioning is used to group related pieces of functionality into packages within subsystems Use Case View (application functionality) Views and Related Diagrams Use Case Diagram Class Diagram Object Diagram Sequence Diagram Activity Diagram Collaboration Diagram Statechart Diagram Component Diagram Deployment Diagram 79 Logical View (static application structure) Process View (dynamic application behavior) Implementation View (application packaging) Deployment View (application delivery) Need to Maintain Consistency and Coverage Across UML Views Functional view DicePersist Architectural View DiceSystem HighScore Displayable Dice Vizuali zation Play Player Observable PersistKit Observer View High Score [ no co ffee ] F ind Be v erage [ no cola ] [ foundcoffee] [ fou nd cola] Pu tC o ffe e in F ilte r Add W ater toR eserv oir G e tC ups G et C a no fC ola Static View P la y er (fro mU seC aseV ie w ) Consistency Coverage 2: r1= roll( ) 1: play( ) gam e: D ice G am e Behavioral View d1: D ie Randomizer Random system JBDC Connection Save/load the highscore Pu t Filter inM ach ine Game Computer SGBD computer R o lls T urn onM ach ine ^coffe ePo t.

Practice 5: Continuously Verify Quality Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change 81 Continuously Verify Software Quality Software problems are 100 to 1000 times more costly to find and repair after deployment Cost to Repair Software Cost of Lost Opportunities Cost Cost of Lost Customers Inception Elaboration Construction Transition 82 .

Test All Dimensions of Software Quality Does my application respond acceptably? Does my application do what’s required? Reliability Verification of sustained application operation Does the system perform under production load? Functionality Verification of each usage scenario Performance Test performance under expected & worst-case load 83 Test Each Iteration Iteration 1 Iteration 2 Iteration 3 Iteration 4 UML Model and Implementation Test Suite 1 Test Suite 2 Test Suite 3 Test Suite 4 Tests 84 .

Practice 6: Manage Change Process Made Practical Best Practices Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change 85 What Do You Want to Control? Changes to enable iterative development Secure workspaces for each developer Automated integration/build management Parallel development Workspace Management Parallel Development CM is more than just check-in and check-out Process Integration REPORT ALERT Build Management 86 .

Aspects of a CM System Change Request Management Configuration Status Reporting Configuration Management (CM) Change Tracking Version Selection Software Manufacture 87 Unified Change Management Management across the lifecycle System Project Management Activity-Based Management Tasks Defects Enhancements Progress Tracking Charts Reports 88 .

Best Practices Reinforce Each Other Best Practices Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change Ensures users involved as requirements evolve Validates architectural decisions early on Addresses complexity of design/implementation incrementally Measures quality early and often Evolves baselines incrementally 89 Part VIII Rational Unified Process 90 .

Foundations of RUP Implement Software Engineering Best Practices: Iterative Controlled Development Use Case Models for Business Requirements Component Architectures Risk Identification. Management & Mitigation 91 RUP Best Practices Implementation Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change Best Practices 92 .

When and How to reach a certain goal.Achieving Best Practices Iterative Approach Guidance for activities and work products (artifacts) Process focus on architecture Use cases which drive design and implementation Models which abstract the system Requirements Analysis & Design Implementation Test Configuration & Change Management 93 A Team-Based Definition of Process A process defines Who is doing What. New or changed requirements Software Engineering Process New or changed system 94 .

baseline architecture – Construction . specify features.Process Structure .Build the product – Transition .Plan project.Define the scope of project – Elaboration .Lifecycle Phases Inception Elaboration Construction Transition time The Rational Unified Process has four Phases: – Inception .Transition the product into end user community 95 Phase Boundaries Mark Major Milestones Inception Elaboration Construction Transition time Lifecycle Objective Milestone Lifecycle Architecture Milestone Initial Operational Capability Milestone Product Release 96 .

Iteration Devel. Architect. Devel.Iterations and Phases Inception Elaboration Construction Transition Preliminary Architect. Iteration Transition Transition Iteration Iteration Minor Milestones: Releases An iteration is a distinct sequence of activities based on an established plan and evaluation criteria. Iteration Iteration Iteration Iteration Devel. resulting in an executable release (internal or external) 97 Workflows Produce Models Core Process Workflows Business Modeling Requirements Analysis & Design Implementation Test Models Implemented By Verified By Realized By Business UseCase Model B B B B Use-Case Model Realized By OK OK Business Object Model Automated By Fail Design Model Implementation Model Test Model 98 .

you walk through all workflows 99 Workflows Guide Iterative Development Business Modeling: Workflow Details Requirements: Workflow Details 100 .Bringing It All Together: The Iterative Approach Workflows group activities logically In an iteration.

or used by a process 101 Use Case Use-Case Package Roles Are Used for Resource Planning Resource Paul Mary Joe Sylvia Stefan Role Designer Requirements Specifier System Analyst Implementer Architect Activities Define Operations Detail a Use Case Find Actors and Use Cases Perform Unit Tests Identify Design Mechanisms Each individual in the project is assigned to one or several roles 102 . modified.Notation A role that may be played by an individual or a team in the development organization A unit of work a role may be asked to perform Activity Role Requirements Specifier responsible for Detail a Use Case Artifact A piece of information that is produced.

Roles Perform Activities and Produce Artifacts Example Requirements: Business Rules Vision Requirements Stakeholder Vision Requests (refined) Supplementary Management Plan Specifications Workflow Detail “Define the System” Requirements Attributes Develop Vision System Analyst Capture a Common Vocabulary Find Actors and Use Cases Use-Case Model (refined) Manage Dependencies Requirements Attributes (refined) Glossary Glossary (refined) Use-Case Modeling Guidelines Business Object Model Business Use-Case Model Use-Case Model Use Case (outlined) 103 Overview of Rational Unified Process Concepts 104 .

defines the boundary and primary features of the system and is used as the basis for more detailed technical requirements Captures all requests made on the project from stakeholders Assesses the impact of all development projects introducing significant architectural or high-level design changes Defines the functional requirements for the system with use case diagrams Defines the nonfunctional requirements of the system Provides a comprehensive architectural overview of the system. scope. benefits and risks of the investment and is used by business sponsors and stakeholders to make an informed decision Defines the stakeholders view of the product to be developed. contains an outline of the envisioned core requirements. costs. sorted in decreasing order of importance and associated with specific mitigation strategies or contingency plans Details the specific tasks that must be completed by each team member in order to complete a project Stakeholders Requests Technology Governance Questionnaire Use Case Specifications Supplementary Specifications Software Architecture Document User Acceptance Test Plan System Test Plan Corporate Report Card Issues List Risk List Project Plan / Iteration Plan Phase Assessment Review 106 Establishes criteria for determining whether or not a project is ready to move from one phase to the next phase . implementation view and data view (as needed) Documents a plan to be used to direct user acceptance testing and ensures that all of the detailed business requirements defined in Inception are tested completely Outlines and communicates the objectives of the testing effort to gain acceptance and approval from the stakeholders Provides measurement and explanation of variances between actual and expected project performance and informs management of project issues (High Risk. using a number of different architectural views to depict different aspects of the system – use case view. resolution. deployment view. and follow-up of project issues Details a list of known and open risks to the project. logical view. process view. review.Summary: Best Practices of Software Engineering Best Practices guide software engineering by addressing root causes Best Practices reinforce each other Process guides a team on what to do. High Impact) Entails the documentation. and when to do it The Rational Unified Process is a means of achieving Best Practices 105 RUP Artifacts Definition Artifacts Investment Concept Statement Business Case Vision Definitions Outlines the project’s purpose. how to do it.

this role details the specification of a part of the organization by describing the workflow of one or several business use cases. shapes priorities. and generally keeps the project team focused on the right goal. for example. The project manager also establishes a set of practices that ensure the integrity and quality of project artifacts. Leads and coordinates technical activities and artifacts throughout the project. Therefore. Provides project leadership and overall business perspective. Business Lead • • Business Project Manager • • Technology Project Manager • Architect • • . the software architect's view 108is one of breadth as opposed to one of depth. In addition. The software architect establishes the overall structure for each architectural view: the decomposition of the view. the grouping of elements. in contrast to the other roles. Allocates resources. and the interfaces between these major groupings. This role is responsible for managing the project risk and working with the team to ensure appropriate communication of risk mitigation. In addition. coordinates interactions with customers and users. and generally keeps the project team focused on the right goal. This role’s overall goal is to ensure the business expectations are achieved on time and on budget. The technology project manager also establishes a set of practices that ensure the integrity and quality of project artifacts. Allocates resources. as well as communicate project progress to Corporate leaders. the Business Project Manager plans and conducts the formal review of the usecase model. establishing what actors and use cases exist and how they interact. They consistently champion the project and associated changes. Leads and coordinates requirements elicitation and use-case modeling by outlining the system's functionality and delimiting the system. Represents the team to stakeholders and management and influences the strategic and tactical business decisions pertaining to the project product. coordinates interactions with customers and users.RUP Core Artifacts Phase Inception Inception Inception Inception Inception Elaboration Elaboration Elaboration Construction Construction Ongoing Ongoing Ongoing Ongoing Ongoing S M L Artifact Investment Concept Statement Business Case Vision Stakeholder Requests Delegated Governance Questionnaire Use Case Specifications Supplementary Specifications Software Architecture Document User Acceptance Test Plan System Test Plan Issues List Risk List Project Plan / Iteration Plan Phase Assessment Review Corporate Report Card Owner Business Sponsor (A) Business Project Manager Business Sponsor (A) Business Project Manager Business Lead (A) Technology Project Manager Business Lead Technology Project Manager Business Lead (A) Technology Project Manager Business Lead (A) Technology Project Manager Technology Project Manager Architect Business Project Manager Project Manager Project Manager Project Manager Project Manager Project Manager Business Project ManagerA 107 = Approver Light Vision Light Vision Light Key Roles/Owners of RUP Artifacts Key Role Business Sponsor Definition • Establishes the project funding and periodically review the spending progress against the Investment Opportunity expectations. shapes priorities.

Management &Mitigation 109 Part IX Introduction to Agile Software Engineering 110 .Key Points RUP focuses on: Iterative Controlled Development Use Case Models for Business Requirements Component Architecture Risk Identification.

following a plan 111 Agile Software Development Ecosystems Agile Software Development Ecosystems (ASDEs) vs. contract negotiation Responding to change vs. comprehensive documentation Customer collaboration vs.Agile Software Engineering Agility “Ability to create and respond to change in order to profit in a turbulent business environment” Agile Values Individual and interactions vs. Traditional Software Development Methodologies Chaordic perspective Product goals are achievable but they are not predictable Processes can aid consistency but they are not repeatable Collaborative values and principles Barely sufficient methodology 112 Agilists are proponents of ASDEs . processes and tools Working software vs.

students will be applying various methodologies to a project of their choice. There will be only one submission per team per deliverable and all teams must demonstrate their projects to the course instructor. As the course progresses.Part IX Conclusion 113 Course Assignments Individual Assignments Reports based on case studies / class presentations Project-Related Assignments All assignments (other than the individual assessments) will correspond to milestones in the team project. 114 . The project will consist of inter-related deliverables which are due on a (bi-) weekly basis. The project and related software system should relate to a real-world scenario chosen by each team. A sample project description and additional details will be available under handouts on the course Web site.

all projects should involve multiple distributed subsystems (e. and database tiers).. if there is an odd number of students in the class. any remaining pair or team members may be arbitrarily reassigned to other pairs/teams at the discretion of the instructor (but are strongly encouraged to reform pairs/teams on their own).which will not necessarily be covered in class. but students are encouraged to form their own 2-pair teams in advance.Course Project Project Logistics Teams will pick their own projects.g. Students will develop and test their project code together with the other member of their programming pair. If some students drop the course. ideally each consisting of two (2) "pairs". web-based electronic services projects including client. Students will need to come up to speed on whatever programming languages and/or software technologies they choose for their projects . There may not be any "pairs" of only one member! The instructor and TA(s) will then assist the pairs in forming "teams". application server. possibly three (3) pairs if necessary due to enrollment. then one (1) team of three (3) members will be permitted. 115 Readings Assignment #1 Team Project proposal (format TBD in class) Presentation topic proposal (format TBD in class) Slides and Handouts posted on the course web site Documentation provided with business and application modeling tools SE Textbook: Chapters 1 & 2 As per references provided on the course Web site Readings Project Frameworks Setup (ongoing) 116 . within certain constraints: for instance. Students will be required to form themselves into "pairs" of exactly two (2) members each.

Next Session: Software Development Lifecycles (SDLCs) Part I Lifecycle Phases Traditional Lifecycle Models Alternative Techniques Homework #1 Project #1 117 .