DOC

Value-based Software Engineering

By Angela Cole,2014-04-19 05:44
12 views 0
Value-based Software Engineering

CSE4002 SE Studio Project Sita Ramakrishnan

Requirements Engineering, Value-based Engineering and IEEE SRS

    Standards

    Class Discussions to revolve around:

    ? Working towards the Functional Specification Document and the Legal Document to be

    signed off by the client

    ? Deed to be signed by each member of the student team

    ? Project Management (see notes on Project Mgmt, PMBOK, reference: Project Management rdPlanning and Control Techniques by Rory Burke, 3 Ed. John Wiley)

    ? Contrast some of the Traditional Planning and Control techniques used in Software

    Engineering against the Value-based Software Engineering

    ? Business case, Stakeholders, Client’s input

    ? Requirements Engineering Processes and Techniques (G Kotonya and I Sommerville, John

    Wiley Publ.)

    o Define what various terms in the Requirements Domain mean

    o Process and techniques associated with Requirements elicitation, requirement

    engineering, requirement management

    o

    ? ANSI/IEEE Standard 830-1998 for Software Requirements Specification from

    http://www.lib.monash.edu.au/databases/i.html from IEEE Explore and Standards and 830

    Also refer SRS Templates from

    http://www.frontiernet.net/~kwiegers/process_assets/srs_template.doc

    http://www.rose-hulman.edu/class/cs/cs414/Examples/SRS/SRSstds-ANSI.doc

………………………………………………………………………………………

Requirements Engineering

    o Process involved in developing system requirements

Requirements Document is a.k.a Functional Specification & a.k.a. System Requirement Specification

    (SRS). The Requirements Document describes:

    o The functionality and services the system should provide

    o Constraints under which the system must operate

    o Other systems which the system must integrate with

IEEE has defined standards for requirements documents. IEEE/ANSI 830-1998 suggests a structure for

    requirements document. Monash Staff & Students can access this document at

    www.lib.monash.edu.au/databases/i.html and visiting IEEE Explore -> Standards ->830 or directly from

    http://ieeexplore.ieee.org/xpl/standards.jsp

Systems Engineering is concerned with system development as a whole and includes hardware,

    software and operational processes. Systems Engineering Process Activities include:

    System Requirement engineering -> Architectural design -> Requirements into subsystems (may have

    hardware & software requirements) -> Software requirements engineering -> h/w & s/w subsystem

    development -> system integration -> System validation.

Some hints and guidelines for writing requirements:

    o Define standard templates for describing requirements - to reduce the likelihood of important

    information being missed, and for ease of reading

    o Consistent language usage be concise, precise, use tables, lists, bullets where appropriate.

    o Use diagrams where appropriate modeling

     1

null

CSE4002 SE Studio Project Sita Ramakrishnan

    Value-based Software Engineering

Researchers in the Economics-Driven Software Engineering Research (EDSER see

    http://www.grabpage.org/~edser/) claim that

    ? Software Engineering Practice and Research is conducted predominantly in a value-

    neutral setting

    ? Decisions in SE are guided by technical considerations and are not clearly aligned to

    maximizing the net payoffs of project costs/investments .

    ? We must recognise that the ultimate arbiter of success in a software project is the net

    value added to the organisation

    ? EDSER’s aim is to advance the theory and practice of software engineering by

    viewing them as value-seeking activities concept of ―value‖ is drawn from

    theoretical insights and advances from finance, strategy, decision theory, game

    theory, politics, etc.

In our SE practice Unit and other Projects undertaken, and as stated in Boehm and Huang’s article

    titled ―Value-based Software Engineering: A Case Study‖ (Computer, IEEE, March 2003, p.33—41),

     we have tended to:

    ? Treat all the requirements, use case, defects etc as equally important.

    ? Use modeling tools to express the design and transform them into implementation.

    ? Use earned value systems to track project cost and schedule (look at our discussion

    on Project management and PMBOK), but not concern ourselves with stakeholder

    or business value.

    ? See S.E ers role as turning requirements into working implementation.

    ? Improvements are seen from a technical perspective alone and not from the

    stakeholder (business) perspective.

Since software is all pervasive in today’s world, and software decision has implications for system cost,

    schedule, and value, it is no longer feasible to adopt a value-neutral paradigm. Such a paradigm cannot

    deal with most software project failures. Boehm states that some of the reasons for project failures are:

    ? Lack of user input.

    ? Incomplete or imprecise or changing requirements.

    ? Unclear objectives, unrealistic expectations and unrealistic timeframes.

A Value-based Software Engineering approach includes the following aspects:

    (see article referred to above and also, Boehm (2003), Value-based Software Engineering, ACM

    Software Engineering Notes)

    ? Requirements Engineering developing a requirements document taking into

    account, the needs (value props) of various stakeholders (anyone affected in some

    way by the ―new‖ system) and reconciling these value props into a acceptable set of

    objectives for the system.

    ? System Architecture reconcile system objectives with various architectural

    solutions.

    ? Design and development with value aspect included

    ? V & V to operate as an investment activity

    ? Planning and control planning and control to include value delivered to the

    stakeholder as well , apart from the traditional view of cost, schedule and milestone.

    ? Risk Management identify, analyse, prioritize and mitigate risk.

    ? Quality Management rank quality factors w.r.t stakeholder’s value props.

    ? People Management include ethical aspects as well as standard mgmt practices.

    ? Principles and practice these include COT based systems, agile methods, RAD,

    high dependability systems and ethics according to Boehm.

     3

Report this document

For any questions or suggestions please email
cust-service@docsford.com