CMSC 435: Software More Resources Engineering Section 0101 • Atif M. Memon (atif@cs.umd.edu) • Class TA • 4115 A.V.Williams building – Bryan Robbins (brobbins@umd.edu) • Phone: 301-405-3071 – (301-405-8162) • Office hours – Office location – .Tu.Th. (10:45am-12:00pm) • AVW 4140 • Don’t wait, don’t hesitate, do – Office hours communicate!! • Mon.Wed (12:00pm-4:00pm) – Phone – E-mail • Course page – Office hours – www.cs.umd.edu/~atif/teaching/spring2010 Back to Software Important: Team Work • Most software is developed • Software uses some of the most – By teams of complex structures ever designed • Designers • Need to apply/develop engineering • Programmers • Managers principles to/for software • Social skills • Software engineering is concerned – Trust other team members with theories, methods and tools • They will develop software components that you may use for professional software • Management skills development – Schedules – Work distribution – Budget 1
A Few Facts About Software Costs Involved Today • Typically • Software costs often dominate – 60% of costs are development costs, system costs. – 40% are testing costs. – The costs of software are often – For custom software, evolution costs often greater than the hardware cost exceed development costs • Costs vary depending on the type of • Software costs more to maintain system being developed and the than it does to develop. requirements of system attributes such – For systems with a long life, as performance and system reliability maintenance costs may be several • Distribution of costs depends on the times development costs development method that is used We will Engineer Software Role of a Software Engineer • But what is software? • Software engineers should adopt a systematic and organised approach – Computer programs and to their work and use appropriate – Associated documentation tools and techniques depending on • Software products may be the problem to be solved, the developed for development constraints and the – A particular customer or resources available – A general market 2
Attributes of Good Software Software Processes • Should deliver the required functionality • What is a Software Process? and performance – A set of activities whose goal is the development or evolution of software • Maintainability • Some Activities: – Software must evolve to meet changing needs – Specification • Dependability • what the system should do and its development – Software must be trustworthy constraints • Efficiency – Development – Software should not make wasteful use of • production of the software system system resources – Validation • Usability • checking that the software is what the customer wants – Software must be usable by the users for – Evolution which it was designed • changing the software in response to changing demands Generic Software Process Software Process Models Models • The waterfall model • A simplified representation of a software process, presented from a specific perspective – Separate and distinct phases of specification • Examples of process perspectives are and development – Workflow perspective • Evolutionary development • sequence of activities – Specification and development are interleaved – Data-flow perspective • Formal systems development • information flow – Role/action perspective – A mathematical system model is formally • who does what transformed to an implementation • Generic process models • Reuse-based development – Waterfall – The system is assembled from existing – Evolutionary development components – Formal transformation – Integration from reusable components 3
Waterfall Model Problems Waterfall Model • Inflexible partitioning of the Requirements Definition project into distinct stages • This makes it difficult to respond System & Software Design to changing customer requirements • Therefore, this model is only Implementation & Unit Testing appropriate when the requirements are well-understood Integration & System Testing Operation & Maintenance Evolutionary Development Evolutionary Development Concurrent • Exploratory development Activities – Objective is to work with customers Initial Specification and to evolve a final system from an Version initial outline specification. Should start with well-understood requirements Outline Intermediate Development Intermediate • Throw-away prototyping Description Versions Versions – Objective is to understand the system requirements. Should start with poorly understood requirements Final Validation Version 4
Formal Systems Development Evolutionary Development • Based on the transformation of a • Problems mathematical specification through – Lack of process visibility different representations to an – Systems are often poorly structured executable program – Special skills (e.g. in languages for rapid prototyping) may be required • Transformations are ‘correctness- • Applicability preserving’ so it is straightforward to show that the program conforms – For small or medium-size interactive systems – For parts of large systems (e.g. the user to its specification interface) • Embodied in the ‘Cleanroom’ – For short-lifetime systems approach to software development Formal Systems Development Formal Transformations Requirements Formal Transformations Definition T4 T1 T2 T3 Formal Executable Formal R1 R2 R3 Specification Program Specification Formal P1 P2 P3 P4 Transformation Proofs of Transformation Correctness Integration & System Testing 5
Formal Systems Development Reuse-oriented Development • Problems • Based on systematic reuse where systems are integrated from existing – Need for specialised skills and training components or COTS (Commercial-off- to apply the technique the-shelf) systems – Difficult to formally specify some • Process stages aspects of the system such as the – Component analysis user interface – Requirements modification • Applicability – System design with reuse – Critical systems especially those where – Development and integration a safety or security case must be • This approach has received a lot of made before the system is put into attention recently operation Reuse-oriented Development Process Iteration Requirements Specification • System requirements ALWAYS evolve in the course of a project so Component process iteration where earlier Analysis stages are reworked is always part Requirements of the process for large systems Modification • Iteration can be applied to any of System Design the generic process models With Reuse • Two (related) approaches Development – Incremental development & Integration – Spiral development System Validation 6
Incremental Development Incremental Development Define Outline • Rather than deliver the system as a Requirements single delivery, the development and Assign Requirements delivery is broken down into increments to Increments with each increment delivering part of the required functionality Design System Architecture • User requirements are prioritized and Develop System Increment the highest priority requirements are Validate included in early increments Increment Integrate • Once the development of an increment is Increment Validate started, the requirements are frozen System though requirements for later increments Final can continue to evolve Version System Incomplete Incremental Development Extreme Programming Advantages • Customer value can be delivered • New approach to development based with each increment so system on the development and delivery of functionality is available earlier very small increments of • Early increments act as a prototype functionality to help elicit requirements for later • Relies on constant code increments improvement, user involvement in • Lower risk of overall project failure the development team and pairwise • The highest priority system services programming tend to receive the most testing 7
Spiral Model of the Software Spiral Development Process • Process is represented as a spiral rather than as a sequence of activities with backtracking • Each loop in the spiral represents a phase in the process. • No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required • Risks are explicitly assessed and resolved throughout the process Spiral Model Sectors Software Specification • Objective setting • The process of establishing what – Specific objectives for the phase are services are required and the identified constraints on the system’s • Risk assessment and reduction operation and development – Risks are assessed and activities put in place to reduce the key risks • Development and validation – A development model for the system is chosen which can be any of the generic models • Planning – The project is reviewed and the next phase of the spiral is planned 8
Recommend
More recommend
