[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"doc-seo-242164-105":3,"detail-sidebar-cat-1-en-105":80,"doc-detail-242164-en":126},{"code":4,"msg":5,"data":6},0,"ok",{"site_id":7,"language":8,"slug":9,"title":10,"keywords":11,"description":12,"schema_data":13,"social_meta":73,"head_meta":75,"extra_data":77,"updated_unix":79},105,"en","software-process-improvement-in-web-time","Software Process Improvement in Web Time","","Software process improvement initiatives can appear unsuitable for fast-moving web development groups, but a five-month experience by a team of about 25 people shows otherwise. The work targeted project management, change control, requirements engineering, and quality practices to handle a large influx of new sitelets. By standardizing common practices, improving post-project review routines, and using templates for plans and requirements, the team increased predictability, stability, and knowledge sharing while maintaining high work quality.",{"@graph":14,"@context":72},[15,34,55],{"@type":16,"itemListElement":17},"BreadcrumbList",[18,23,27,31],{"item":19,"name":20,"@type":21,"position":22},"https://docshare.wps.com","Home","ListItem",1,{"item":24,"name":25,"@type":21,"position":26},"https://docshare.wps.com/template/","Template",2,{"item":28,"name":29,"@type":21,"position":30},"https://docshare.wps.com/template/presentations/","Presentations",3,{"item":32,"name":10,"@type":21,"position":33},"https://docshare.wps.com/template/software-process-improvement-in-web-time/242164/",4,{"url":32,"name":10,"@type":35,"image":36,"author":41,"headline":10,"publisher":44,"fileFormat":47,"inLanguage":8,"description":12,"dateModified":48,"datePublished":49,"encodingFormat":47,"isAccessibleForFree":50,"interactionStatistic":51},"DigitalDocument",{"url":37,"@type":38,"width":39,"height":40},"https://docshare.wps.com/thumbnails/software-process-improvement-in-web-time/242164.png","ImageObject",442,249,{"name":42,"@type":43},"Đào","Person",{"url":19,"name":45,"@type":46},"DocShare","Organization","application/pdf","2026-10-11","2026-09-12",true,{"@type":52,"interactionType":53,"userInteractionCount":26},"InteractionCounter",{"@type":54},"ViewAction",{"@type":56,"mainEntity":57},"FAQPage",[58,64,68],{"name":59,"@type":60,"acceptedAnswer":61},"Why did the Web development group pursue software process improvement?","Question",{"text":62,"@type":63},"Development and management processes did not keep pace with increasing project demands, team growth, and a growing backlog of sitelet requests. The group committed internal effort to improve management, quality, and productivity while handling the influx of new work.","Answer",{"name":65,"@type":60,"acceptedAnswer":66},"What areas did the team target during the five-month process improvement?",{"text":67,"@type":63},"The team tackled project management, change control, requirements engineering, and quality practices. They also addressed gaps such as peer reviews, testing, problem tracking, and project planning, along with weaknesses in the web site creation process.",{"name":69,"@type":60,"acceptedAnswer":70},"How did the team use the Capability Maturity Model (CMM) in their approach?",{"text":71,"@type":63},"They referenced level 2 key process areas as a basis for understanding their problems. Instead of pursuing a strict CMM compliance path, they used CMM as a guide to achieve desired results like predictability and stability without dogmatic adoption.","https://schema.org",{"og:url":32,"og:type":74,"og:title":10,"og:site_name":45,"og:description":12},"article",{"robots":76,"canonical":32},"index,follow",{"doc_id":78,"site_id":7},242164,1791724589,{"code":4,"msg":81,"data":82},"success",[83,87,92,97,102,107,112,117,122],{"id":84,"doc_module":22,"doc_module_name":25,"category_name":29,"show_sort_weight":85,"slug":86},11,90,"presentations",{"id":88,"doc_module":22,"doc_module_name":25,"category_name":89,"show_sort_weight":90,"slug":91},12,"Resumes",80,"resumes",{"id":93,"doc_module":22,"doc_module_name":25,"category_name":94,"show_sort_weight":95,"slug":96},14,"Invoices",70,"invoices",{"id":98,"doc_module":22,"doc_module_name":25,"category_name":99,"show_sort_weight":100,"slug":101},15,"Posters",60,"posters",{"id":103,"doc_module":22,"doc_module_name":25,"category_name":104,"show_sort_weight":105,"slug":106},16,"Social Media",50,"social-media",{"id":108,"doc_module":22,"doc_module_name":25,"category_name":109,"show_sort_weight":110,"slug":111},17,"Forms",40,"forms",{"id":113,"doc_module":22,"doc_module_name":25,"category_name":114,"show_sort_weight":115,"slug":116},18,"Letters",30,"letters",{"id":118,"doc_module":22,"doc_module_name":25,"category_name":119,"show_sort_weight":120,"slug":121},21,"Paper Templates",5,"papers-templates",{"id":123,"doc_module":22,"doc_module_name":25,"category_name":124,"show_sort_weight":4,"slug":125},158,"General","general-158",{"code":4,"msg":81,"data":127},{"doc_id":78,"user_id":128,"nickname":42,"user_avatar":129,"doc_module":22,"category_id":84,"category_name":29,"doc_title":10,"doc_description":12,"doc_content":130,"file_id":131,"file_url":132,"file_type":133,"file_size":134,"view_count":120,"is_deleted":4,"is_public":22,"is_downloadable":22,"audit_status":22,"page_count":135,"language":136,"language_code":8,"site_id":7,"html_lang":8,"table_of_contents":137,"faqs":138,"seo_title":139,"seo_description":12,"update_tm":140,"read_time":30},1374402968488,"https://ap-avatar.wpscdn.com/davatar_29158cc5080c5b710cf443261637dec0","Software Process Improvement in Web Time1  \nKarl E. Wiegers  \nProcess Impact  \n716-377-5110  \n[www.processimpact.com](www.processimpact.com)  \nMuch of the software process improvement literature describes how large corporations and government contractors have changed their software development and management processes over a long period of time. Commercial application developers and Web development groups sometimes conclude that process improvement doesn’t apply to, and isn’t feasible for, their time scales, product types, and cultures.  \nNot so! This article relates the five-month process improvement experience of a team of about 25 people doing Web development at a major corporation. We tackled areas including project management, change control, requirements engineering, and quality practices. The tangible and cultural benefits we achieved have the potential to help this group meet its commitments to deliver Web applications (“sitelets”) in the very public eye: the company’s 41,000-page Web site averages more than one million hits per day.  \nThe software practice areas the group chose to improve are neither novel nor profound. Indeed, that is a significant message. Even a group that undertakes fast-paced Web projects can benefit from the application of traditional software process improvement approaches. Like any other project, Web projects have users, requirements, schedules, resources, and quality goals. Superior technical and management processes can yield superior results in the world of Web time, just as in any other software development setting.  \nTHE GROUP  \nThe Web development group at Eastman Kodak Company began several years ago with just a few people developing simple sites. They soon experienced rapid growth in team size, application size and complexity, and the number of new sitelets requested by business units. The group came to include a software architecture team of about a dozen highly experienced and talented developers and a “customer experience” team with about 10 young, creative visual designers and several human factors specialists.  \nUnfortunately, development and management processes did not evolve in parallel with work demands. Practices that worked well for a few people doing small projects were not adequate for the larger teams, more complex projects, and backlog of requests that came about over time. This led to the group’s internal commitment to focus some energy on process improvement. Their goals included  \n♦ managing the huge influx of new work  \n♦ developing a foundation of common practices to help new team members quickly become effective  \n♦ maintaining the high quality of work while improving productivity  \n♦ exchanging knowledge effectively among group members  \nEach project is assigned a multifunctional team, to avoid the expectation that everyone be a fully  \n1 This paper was originally published in IEEE Software, July/August 1999 © 1999 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.  \nproficient generalist. A typical project team might include a project leader, a technical lead, a design lead, a business unit representative, a software developer, a database expert, and a human factors expert. One consequence of this structure is that each team member works on several projects at once, with the accompanying challenge of setting priorities and the inefficiency caused by frequent task switching and many communication interfaces.  \nSome development infrastructure and process was already in place in this group, including a recommended Web site creation process. However, there was considerable variation in the ways different individuals performed common activities, and many holes remained in the development, manag","cbCailmwiElb7HvH","https://ap.wps.com/l/cbCailmwiElb7HvH","pdf",38194,9,"English","# Process Impact\n## Team Experience and Context\n## Approach and Focus Areas\n## Process Improvement Using CMM Guidance","[{\"question\":\"Why did the Web development group pursue software process improvement?\",\"answer\":\"Development and management processes did not keep pace with increasing project demands, team growth, and a growing backlog of sitelet requests. The group committed internal effort to improve management, quality, and productivity while handling the influx of new work.\"},{\"question\":\"What areas did the team target during the five-month process improvement?\",\"answer\":\"The team tackled project management, change control, requirements engineering, and quality practices. They also addressed gaps such as peer reviews, testing, problem tracking, and project planning, along with weaknesses in the web site creation process.\"},{\"question\":\"How did the team use the Capability Maturity Model (CMM) in their approach?\",\"answer\":\"They referenced level 2 key process areas as a basis for understanding their problems. Instead of pursuing a strict CMM compliance path, they used CMM as a guide to achieve desired results like predictability and stability without dogmatic adoption.\"}]","Software Process Improvement in Web Time | PDF",1789187309]