1 / 23

IS 556 Project Management

IS 556 Project Management. Week 7 - Software Development Standards Readings: On Time Within Budget - Chpt 9 Case: Bell South. David Lash. Overview. Why use standards What are main standard bodies IEEE - Institute of Electrical and Electronics Engineers

papina
Download Presentation

IS 556 Project Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IS 556 Project Management Week 7 - Software Development Standards Readings: On Time Within Budget - Chpt 9 Case: Bell South David Lash

  2. Overview • Why use standards • What are main standard bodies • IEEE - Institute of Electrical and Electronics Engineers • ISO - International Standards Organization • DOD - US Department of Defense. • Using Standards

  3. Software Development and Standards • A necessary evil? • Limit developer freedom • One-size-fits all danger • Why create standards? • Makes software management manageable • Help software developers understand others work • E.g., Perl standard will document regular expressions. if ( /^[01]d/[0123]d/2ddd$/ ) { if (/^[01]d/ # look for month mm /[0123]d/ # day mm /2ddd$/w ) { # Year yy - century

  4. Why Standards? • Case from Text • Aereola development. • XT2000 need new user interface. • Estimate between 1.5-2 years to develop • 4 hot-shot developers propose add-on PC interface • 2-3 months to develop • temporary until “real” one developed • Cut corners on standard to get done on time. • 4 years later user interface not done, no original 4 around • New team created -> No idea of design, missing source, code hacked up.

  5. Does that really happen • Maintaining Web-based form package • Package keeps track of quality records for inspections. • Only 1 developer for 2-3 years. • No design, no code reviews, no code control • Develop leaves company, new person assigned • Has to reverse engineer design • Discovers ugly code, f-file based instead of DB. • Corrupted form states.

  6. Which Standard to Use? • Moore (98) - There are > 300 development standards maintained by > 50 organizations • Most common • IEEE - Institute of Electrical and Electronics Engineers • ISO - International Standards Organization • DOD - US Department of Defense.

  7. IEEE • One of first software engineering standards: 1984 • Included 4 development standards • requirements, quality assurance, testing and configuration management. • Fifth volume later include standard definitions & terms • 1999 - 4 volume standards collection • Standard can be used for • A recommended practice, A guide, a standard or supplement to standard • 1999 volumes (contained 40 standards) • Customer and terminology • Process • Product standards • Resource and technique

  8. IEEE 1999 SE Stds - Volume 1 • Customer and Terminology Standards • Pages 192-193 list Process standards, product standards and resource and technique standards

  9. IEEE Standard Layers Figure 9.2

  10. An example standard - IEEE Std 830Software Requirements Specification Basic Characteristics • Started in 1983 and upgraded many time since • Does each requirement accurately represent the expectation of the customer? (correct) • Is each requirement clear and does it have the same interpretation for all who read it? (unambiguous) • Are all requirements documented, have we ensured that no "verbal" understandings remain? (complete) • Can we prove in a reasonable manner, and at a reasonable expense, that each requirement has been met? (verifiable) • Does any requirement conflict with another requirement? (consistent) • In determining future trade-offs, has the relative importance of each requirement been assigned? (ranked) • Is the requirements specification documented in a way that will enable it to be easily corrected or changed later? (modifiable) • Are the origins of each requirement clear (backward traceability), and can the testing and design documents be later traced to requirements? (forward traceability) • Has the requirement specification been written so that it can be understood not only by the organization writing it, but also by the software maintenance organization? (usable) • Best use for non-evolutionary models.

  11. An Example IEEE Standard • IEEE 610.12 - Glossary of standard Terminology • Covers 1300 Software Engineering terms: • compilers • configuration management • Operating system • Errors, faults, failures • Quality attributes • Some terms with multiple definitions such as: • Quality - 2 separate definitions - 1 related to requirements another related to customer expectations • Patch - 4 separate definitions Not the only definition set others include ISO and DOD.

  12. IEEE Software lifecycle standards • Std 12207 Purpose: • to establish common framework for software life cycle processes. • Contains • software processes, activities and tasks for software acquire, development, operation, support • Centers on 5 views of software lifecycle • contract, engineering, operating and maintenance, supporting processes (E.g., documentation, configuration, q/a) Organizational (management, infrastructure, training)

  13. Fig 9.5 STD12207Software Life Cycle Processes

  14. ISO - International Organization for Standards • Initially European body now have world wide membership • ISO members offered to national bodies • Bodies apply and adapt standard to country • USA is represented by ANSI (American National Standards Institute) • Famous for ISO 9000 - Standard concerned with Quality Management • ISO 9001 – business ranges from design to build to install to service • ISO 9002 – business does not design and develop • ISO 9003 – business does testing and inspection

  15. ISO vs IEEE • Standards are similar to IEEE with differing terminology • Overall guide is ISO 9000 • Software also falls under the 9001-9002 guides depending on company • ISO 9004 describes quality management • 4 additional volumes of standards define quality terminology, quality plan standards, configuration management, quality audit plans • ISO 9000 are developed an maintained by technical committee 176 • Has been American Society of Q/C (ASQC)

  16. IEEE Standards • Advantages • Flexible - can adapt as needed • Standards may be used independently • Relatively easy to use - Examples are given • Disadvantages • Not used worldwide • Allow too much flexibility • Implementers define how they are used

  17. ISO • Advantages • Extensive coverage - Cover everything and more • Adopted - Many are used by IEEE • Detailed - Detailed and not very flexible • Acceptance - Wide International acceptance • Certification - Adoption can lead to ISO 9000 certification • Disadvantages • More difficult to use - • Cover everything and more • Detailed and not very flexible • Complicated

  18. DOD and other • Bodies such as DOD, NASA and European Space Agency (ESA) Std 2167A • Create own standards for areas consider ill-defined • DOD - An extremely large software customer. • Much work done before stnds bodies firmly established (eary 1980s) • Std 2167 - specified software documentation, reviews. • STD2167 supervision tool • STD2167A developer tool • Eventually became IEEE 12207

  19. STD 2167A • In 1985 for mission critical defense software systems. • A leader until 1998 and IEEE/EIA 12207 adopted. • Objective: establish uniform requirements throughout project lifecycle • Inclined to phased methodologies such as Waterfall (but with some difficulty can use others) • Data Item descriptions defines project document standards. E.g., • software development plan, requirements specification, design document, interface description, version description, test plan, test report, operators manual, users manual, etc. • Review and audit control tools built in • where decisions are finalized

  20. More on STD 2167A • Major baseline (gates) • fucntional baseline - finalizes users view of system • allocated baseline - finalizes software requirements • Critical design baseline - finalize design • product baseline - finalizes the software development • Contractors required to tailor the standard • done by deleting non-applicable items • 2167 “issues” • Generated a lot of paperwork • Not well suited to small projects • But customer was involvement in process

  21. DOD 2167a software development approach Fig. 9.6 DOD STD 2167A

  22. Using Standards • A standard should • provide a framework for good practices • When practice inefficient should support replacement • Needs to be implemented correctly • Enforcing standard use can be difficult • Often requires upper management • Need to figure out how to measure if being used. • Expect resistance to change

  23. Summary • Why use standards • What are main standard bodies • IEEE - Institute of Electrical and Electronics Engineers • ISO - International Standards Organization • DOD - US Department of Defense. • Using Standards

More Related