1 / 30

IS 556 Project Management

IS 556 Project Management. Week 5 Project Support Functions Readings: On Time Within Budget - Chpt 8 Software Project Survival Guide chpts: 6,7,8, 9

bradley-mullen
Télécharger la présentation

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 5 Project Support Functions Readings: On Time Within Budget - Chpt 8 Software Project Survival Guide chpts: 6,7,8, 9 Case: Case: HCL America   Presenter Group [Group 3 - Rolling Meadows - Case: HCL America ]Case: Concorddia Presenter Group [Group 12 - Concordia] David Lash

  2. Objectives: • 4 major Project support functions: (include SSG 6,7,9) • Configuration Control, • Change Control • SQA, • Testing • Some notes on Requirements (SSG chapt 8)

  3. Project Support Functions • Major Project support functions: • Configuration control • Change Control • Software Quality Assurance • Testing • Support Group(s) are overhead to development • Its size increases with project size • May be 1-2 engineers, a group or whole dept

  4. Software Configuration Control • Configuration => combination of software components that form integrated system • Configuration control => method of managing software components to make product(s). • Supports software development activities • Program code changes • Requirement changes • Design changes • Version release changes

  5. Software Configuration Management • No standards but IEEE definitions • Change control - the process of controlling software changes. (i.e., approving, evaluating, rejecting). • Version control - process of controlling software versions, (i.e., saving, documenting.) • Software Configuration control - Engineering discipline to provide methods and tools to control product configurations • Biggest Problems • Lack of management plan for change control • Development team ignorance of plan and requirements on them

  6. Configuration Control Needs • As early as 1970s, version and change control tools available (e.g, make, sccs) • Effective change control requires: • Change control authority (need process owner/mgr) • Standards, procedures, and guidelines (e.g., all external software => change control) • Need tools and resources: • CASE tools • Automated configuration control tools • Repository (w/ daily backups, sync between sites) • Could be part of overall project plan (could be part of overall standard process) PM responsibility to assign config management authority?

  7. Table 1.8 - Software config mgmt plan Its likely there is a standard for organization. If not would need to define.

  8. Change control Board review Figure 8.3: Configuration Control Flow Chart from US DOD-Std-2167A

  9. A Change Request Form … Many shops automate this process with tools that document/track/archive requests. (e.g., webased r-trackers)

  10. Sft S. Guide Ch 6- Issues • Change control separate from configuration control. • On-going assessment of change requests. • Create a Change panel or board • Members include representatives from key areas such as marketing, development, SQA, project management. • (might be much smaller for small projects) • Seek to fully understand change requests and decide priority. • Assess changes, lets affected areas review, and lets them now when change approved.

  11. Advantages of Change Control • Changes systematic • Customers understand change requests will be assessed for impact. • Decisions have full input • Milestones are firmed up • Formal Accountability • Revision and version control • Sharing of all documents

  12. Change assessment includes ... • What is benefit of change • How does change affect • Cost - How difficult is the change to make? • Quality - Can it destabilize software • Resource Allocation • Can the change be deferred?

  13. Change Assessment Problems • Politics • Usually not implemented or not done well • What products must be included? • Commitment

  14. Software Quality Assurance (SQA) • What is SQA? • IEEE 1999: The degree to which a system, component, or process meets specified requirements. • The degree to which a system, component, or process meets customer needs or expectations.

  15. Aspects of Quality • Three aspects of Product quality • Objective – measurable characteristics from requirements • Subjective – Compliance with customer expectations • Non-assessable – behavior in unforeseen situations • To create quality software quality move requirements from subjective -> objective list

  16. QA Rules • Poor quality breeds failed systems • Software failure can be avoided • It is cheaper to design product correctly than to correct it after release • QA should be an integrated part of development • QA is ongoing from the beginning of system design

  17. Quality Assurance • Part of project plan • Old School SQA = Testing • Now QA = • Testing, Planning • Early detection • Quality metrics, Process metrics (e.g., review) • SQA plan must be developed • Committed to in writing • Begin at requirements definition • Separate, trained, SQA group w/ adequate funding

  18. Example SQA Plan (Pg 174)

  19. Software Quality Metrics • Development Quality Metrics = measurable values to help understand quality of product. • How can you measure product quality? • Recoverability - MTTR • Reliability - MTTF - Failure rate • Usability - training time required, customer perception • Performance - Speed of execution • Defect Reports - Failure to meet requirements • Can be used throughout product lifecycle.

  20. Defects Need to be Tracked • Begin tracking defects at the requirements level • Separate defect reports • Emphasize importance to developers • Provides valuable data to management (release management later) • Can ask questions like: • Amount of open defects • Number of defects from last release • Number of serious defects from last release • Defects per release over time • Number of defects caused per stage per release

  21. Testing and Tech Reviews or Code Walkthrough • Technical Reviews • Schedule them starting early in project • Code cannot progress without review • Review points: • Preparation: Record prep time. • If not enough preparation, this is logged and meeting is postponed. • Need author, moderator, defect recorder. • State of review is decided by team: • “re-review”, “Pass with modifications”, “Pass” • Follow is required for some states. • Foster correct attitude. • Record Review statistics by SQA • Results are public • Includes: what’s been reviewed, defects, state, etc.

  22. Software Testing • Ongoing process • Does software satisfy requirements? • Are customer’s happy with it? • Developer cannot adequately test own code • Different mindset of developer VS test engineer. • Test Types Includes: • unit - developer testing of individual modules integration - modules assembled and tested subsystem - testing assembles subsys together regression - rerunning complete set of tests with integrated system to assure things still work. alpha - complete system w/o live data), beta - using live data) and acceptance testing - end user acceptance

  23. Formal Testing Procedure • IEEE Standard 829 includes • Test plan - definition of the overall test approach, resources and schedule • Test design specs - identifies specific features to test • Test cases specifications - identifies and describes the test cases • Test procedures - describes how to run tests • Logs - test results • Test summary - summarizes test results.

  24. More on Testing • Traceability • Each feature has a source in requirements • Each requirement has a feature implemented • Full coverage – complete testing • Have we tested everything that needs testing? • Maintain a test coverage report to ensure cover all requirements • Test plans begin when requirements are known: • When you write requirements have tests in mind • Use of test groups

  25. Software Project Survival Guide Ch. 8 Requirements Development

  26. Requirements Development • What do customers need? • Figure out a key set of customers • Talk/interview them • Formalize their needs and lead them through process • Biggest problem: users don’t always know what they need • Specify now… save on coding and correction later

  27. User Spec Prototype Remember if build user interface prototype, your supposed to through it away. ID End Users Interview Build User Prototype(e.g. Storyboard, Wireframe) Make Extensions Treat Fully Extended Prototype as Baseline Spec

  28. Last Week Objectives • Project Plan • Work Breakdown Structure • Pert Chart • Gannt Chart • Dealing with Human Resources

  29. Summary • 3 major Project support functions: (include SSG 6,7,9) • config control, • Change control • SQA, • Testing • Some notes on Requirements (SSG chapt 8) • prototype

  30. Summary • Stepwise Estimation • Prototyping – Engineering orientation • Constructive Cost Models • Estimate project in 5 levels 1. Level of Personnel 2. Level of complexity 3. Project size 4. Development Environment 5. Reliability level • Range of Estimates (normal distribution) • Hardware estimates - CPU, Memory, disk, resp time

More Related