Presentation of 3 slides 3 slides for topic — System development life cycle. Below is the Course material PPT and JOURNALS to refer for the topic. -

Presentation of 3 slides
3 slides for topic — System development life cycle. Below is the Course material PPT and JOURNALS to refer for the topic.
Make sure to provide citations and 2 references. Need this in 2 hours please.

Chapter 13
Project Management and SDLC

Don't use plagiarized sources. Get Your Custom Assignment on

Presentation of 3 slides 3 slides for topic — System development life cycle. Below is the Course material PPT and JOURNALS to refer for the topic.

From as Little as $13/Page

Prepared by Dr. Derek Sedlack, South University

Learning Objectives

Project Planning, Execution, and Budget

Project Monitoring, Control, and Closing

System Development Life Cycle

Project Management Concepts

Project Management Concepts
Deliverable
Items that you hand off to the client or management for their review and approval and that must be produced to complete a project or part of a project.
Project Portfolio Management (PPM)
Set of business practices to manage projects as a strategic portfolio.
Business Case
Identifies an opportunity, problem, or need and the desired business outcomes of the project.

Chapter 13

Project Management Concepts
Project Portfolio Management Path

Chapter 13

Map proposed projects to organizational strategies.

Assess the value that a proposed project brings to the company.

Assess the complexity of proposed projects.

Prioritize project proposals for project selection.

Project Management Concepts
Operations vs. Projects
Operations
Business as usual
Projects
Clearly defined scope, deliverables, and results.
Estimated time frame or schedule subject to a high degree of uncertainty.
Estimated budget subject to a high degree of uncertainty.
Requirement of extensive interaction among participants.
Tasks that may compete or conflict with other business activities.
Risky but with a high profit potential or benefits.
Chapter 13

Project Management Concepts
Chapter 13

Figure 13.3 Project success triple constraint.

Scope

Time

Project
Success

Cost

Project Management Concepts
Scope Creep
Project growth is the piling up of small changes that by themselves are manageable but in aggregate are significant.
Contributes to overages in budget, deadline, and/or resources.
Standard project management approaches reduce scope creep.
Chapter 13

Project Management Concepts
What is a deliverable?
What is the purpose of PPM?
What distinguishes a project from operations?
What are the triple constraints?
How can scope creep contribute to project failure?
What identifies an opportunity, problem, or need and the desired business outcomes of the project?
What is the approach that examines projects holistically and manages them as a strategic portfolio?
What are the items that you hand off to the client or management for their review and approval?
What are the three attributes that must be managed effectively for successful completion and closure of any project?
What is the term for the piling up of small changes that by themselves are manageable but in aggregate are significant?
Chapter 13

Suggested Answers:

1. A deliverable is an item that you hand off to the client or management for their review and approval and that must be produced to complete a project or part of a project.

2. PPM is a set of business practices to manage projects as a strategic portfolio. PPM ensures the alignment of programs and projects with organizational objectives.

3. Projects differ from operations or business as usual based on these characteristics of a project:
Clearly defined scope, deliverables, and results
An estimated time frame or schedule that is subject to a high degree of uncertainty
An estimated budget that is subject to a high degree of uncertainty
The requirement of extensive interaction among participants
Tasks that may compete or conflict with other business activities, which makes planning and scheduling difficult
Risky but with a high profit potential or benefits

4. The triple constraint refers to the three attributes that must be managed effectively for successful completion and closure of any project:

Scope. The project scope is the definition of what the project is supposed to accomplishits outcomes or deliverables. Scope is measured in terms of the project size, goals, and requirements.
Time. A project is made up of tasks. Each task has a start date and an end date. The duration of a project extends from the start date of the first task to the finish date of the last task. Time needed to produce the deliverables is naturally related to the scope and availability of resources allocated to the project.
Cost. This is the estimation of the amount of money that will be required to complete the project. Cost itself encompasses various things, such as resources, labor rates for contractors, risk estimates, and bills of materials, et cetera. All aspects of the project that have a monetary component are made part of the overall cost structure. Projects are approved subject to their costs.

These constraints are interrelated so they must be managed together for the project to be completed on time, within budget, and to specification.

5. Scope creep refers to the growth of the project, which might seem inconsequential to the requestor. Scope creep is the piling up of small changes that by themselves are manageable but in aggregate are significant.

6. A Project Business Case.

7. Project portfolio management (PPM) is a set of business practices to examine projects holistically and manage them as a strategic portfolio.

8. A deliverable is an item that you hand off to the client or management for their review and approval and that must be produced to complete a project or part of a project.
In this section, the project Business Case and Statement of Work are items needing approval.

9. The triple constraint refers to the three attributes that must be managed effectively for successful completion and closure of any project: Scope, Time, and Cost.

10. Scope creep.
8

Learning Objectives

Project Planning, Execution, and Budget

Project Monitoring, Control, and Closing

System Development Life Cycle

Project Management Concepts

Project Planning, Execution, and Budget
Project Business Case
Identifies an opportunity, problem, or need and the desired business outcomes of the project.
Statement of Work (SOW)
A definitive statement that defines the project plan, but does not offer any options or alternatives in the scope.
After the project plan in the SOW is reviewed, a go or no-go decision is made.
Go/No-Go Decision
Formal decision made by PM, sponsor, and appropriate executives and stakeholders.

Chapter 13

Project Planning, Execution, and Budget
Chapter 13
13.4 Project management key stages and activities.
Business case & SOW
Project plan review using PPM; then go/no-go decision
Project initiation & risk management planning
Project execution, tracking & control
Project closure & lessons learned

Project Planning, Execution, and Budget
Work Breakdown Structure (WBS)
Identifies all work or activities that need to be performed, the schedule of work, and who will perform the work.
Milestones
Used to manage the project work effort, monitor results, and report meaningful status to project stakeholders.
Crowdfunding
Raising funds for a project from the public, or crowd, via the Web.
Chapter 13

Project Planning, Execution, and Budget
Responsibility Matrix
Shows who has primary responsibility and who has support responsibility for the activities listed in the WBS.
Gantt Chart
A bar chart that shows the timeline of the project schedule.
Chapter 13

Project Planning, Execution, and Budget
Baseline (Master Plan)
Finalized and accepted project plan.
Changed only through formal change control processes.
Variance
Any change to the baseline.
Crowdfunding
Raising funds for a project from the public, or crowd, via the Web.
Chapter 13

Project Planning, Execution, and Budget
If the business case is accepted, what document is prepared?
What events are used to manage the project work effort, monitor results, and report a meaningful status to project stakeholders?
What is the longest path of tasks through a project?
What shows who has primary responsibility and who has support responsibility for the tasks listed in the WBS?
What is the type of bar chart that shows the timeline of the project schedule?
When the project plan is finalized and agreed to, what is any change to the baseline?
Chapter 13

Suggested Answers:

1. If the business case is accepted, a statement of work (SOW) is prepared.

2. Milestones are used to manage the project work effort, monitor results, and report meaningful status to project stakeholders.

3. A critical path is the longest path of tasks through a project.

4. A responsibility matrix shows who has primary responsibility and who has support responsibility for the activities listed in the WBS.

5. A Gantt chart is a horizontal bar chart that graphically displays the project schedule.

6. Any change to the baseline is a deviation, or variance, to the planand it needs to be documented.

Learning Objectives

Project Planning, Execution, and Budget

Project Monitoring, Control, and Closing

System Development Life Cycle

Project Management Concepts

Project Monitoring, Control, and Closing
Integrated Change Control
Process helps to manage the disruption resulting from requested changes and corrective actions across the project life cycle.
Required to defend:
Approved/rejected change requests
Updates to the project plan/scope
Approved corrective and preventive actions
Approved/validated defect repair
Chapter 13

Project Monitoring, Control, and Closing
Critical Path
Longest path of tasks through a project. Extends the length of the project with delays unless something is done to compensate. Contains critical tasks or activities.
Critical Tasks
Tasks or activities on the critical path that must be completed on schedule in order for the project to finish on time.
Noncritical tasks
Tasks or activities not on the critical path, but may go critical if delayed enough.
Chapter 13

Project Monitoring, Control, and Closing
Chapter 13

13.8 Project controls.

Project Monitoring, Control, and Closing
Project Control
Used to identify when to declare the ongoing project a failure and kill it.
Sunk Cost
Money already spent on the project.
Chapter 13

Project Monitoring, Control, and Closing
Project Closing and Postmortem
Project closure does not benefit the completed project.
The enterprise and people who worked on the project benefit.
Post-project reviews, or postmortems, identify the reasons the project was successful or not, strengths and weaknesses of the project plan, how problems were detected and resolved, and how the project was successful in spite of them.
Chapter 13

Project Monitoring, Control, and Closing
What processes help to ensure that the impacts resulting from requested changes and corrective actions are managed across the project life cycle?
What is the length of a project?
Assuming no changes are made, what happens when a task on the critical path is delayed?
What costs should not be considered when deciding whether to kill a project?
When are lessons learned from a completed project identified?
Chapter 13

Suggested Answers:

1. Integrated change control processes help to manage the disruption resulting from requested changes and corrective actions across the project life cycle.

2. The critical path is the length of the project.

3. The entire project is delayed.

4. The money already spent on the project, or sunk costs, should not be considered in the decision.

5. These are identified during the post-project review, or postmortem.

Learning Objectives

Project Planning, Execution, and Budget

Project Monitoring, Control, and Closing

System Development Life Cycle

Project Management Concepts

System Development Life Cycle
System Development Life Cycle (SDLC)
The traditional system development method for large IT projects, such as IT infrastructure or an enterprise system.
A structured framework that consists of a sequential set of processes.
Highly susceptible to scope creep through:
Additional feature requests
Unnecessary stakeholders
Technological change/improvement

Chapter 13

System Development Life Cycle
Chapter 13
System Development Life Cycle
Objectives
Expectations
Specifications

Initial Idea

Requirements Analysis

System Analysis

Development

Implementation

Maintenance

System Development Life Cycle
Requirements Analysis
Deficiencies are identified and used to specify new system requirements.
More time invested in analysis mean greater probability of IS success.
System Analysis
Design of the proposed system.
Feasibility Studies
Technical, Economic, Legal and Organizational, and Behavioral.

Chapter 13

System Development Life Cycle
System Development
Creation based on functional objectives to solve the business problem.
Testing
Verification that apps, interfaces, data transfers, etc., work correctly under all possible conditions.

Chapter 13

System Development Life Cycle
Implementation
Conversion of the old system to the new system.
Parallel: simultaneous transfer
Direct: cut off and migration
Pilot: test new than roll out
Phased: specific components in stages
Maintenance
Perform audits to assess capabilities and determine operational correctness.

Chapter 13

System Development Life Cycle
What are the stages of the SDLC?
Why is information system design highly susceptible to scope creep?
What can be done to prevent runaway projects?
Explain the feasibility tests and their importance.
What are four conversion methods?
Chapter 13

Suggested Answers:

1. The systems development life cycle (SDLC) is the traditional systems development method for large IT projects, such as IT infrastructure or an enterprise system. The SDLC is a structured framework that consists of a sequential set of processes. Starting with an initial idea, the SDLC processes are requirements analysis, systems analysis and design, development and testing, implementation, and maintenance.

Each process consists of well-defined tasks that depend on the scope of the project. The processes are iterative, which means that they are revised when new information or conditions make a revision the smart thing to do. Iteration does not mean that system development should be subject to infinite revisions or scope creep.

2. IS design is highly susceptible to scope creep for many reasons. Intended users ask for additional features. People who were not intended users ask to be included. Technology changed from the time the business case was written and system development began. The actions of a competitor, supplier, or regulatory agency triggered additional requests for functionality.

3. Because scope creep is expensive, project managers impose controls on changes requested by users. These controls help to prevent runaway projects.

4. The feasibility study determines the probability of success of the proposed project and provides a rough assessment of the projects technical, economic, organizational, and behavioral feasibility. The feasibility study is critically important to the systems development process because, done properly, the study can prevent organizations from making expensive mistakes, such as creating systems that will not work, that will not work efficiently, or that people cannot or will not use. The Census Bureau case in IT at Work 13.1 is an example. The various feasibility analyses also give the stakeholders an opportunity to decide what metrics to use to measure how a proposed system meets their objectives.
Technical Feasibility. Technical feasibility determines if the required technology, IT infrastructure, data structures, analytics, and resources can be developed and/or acquired to solve the business problem. Technical feasibility also determines if the organizations existing technology can be used to achieve the projects performance objectives.
Economic Feasibility. Economic feasibility determines if the project is an acceptable financial risk and if the company can afford the expense and time needed to complete the project. Economic feasibility addresses two primary questions: Do the benefits outweigh the costs of the project? Can the project be completed as scheduled?
Management can assess economic feasibility by using costbenefit analysis and financial techniques such as time value of money, return on investment (ROI), net present value (NPV), and breakeven analysis. Return on investment is the ratio of the net income attributable to a project divided by the average cost of resources invested in the project. NPV is the net amount by which project benefits exceed project costs, after allowing for the cost of capital and the time value of money. Breakeven analysis calculates the point at which the cumulative cash flow from a project equals the investment made in the project.
Calculating economic feasibility in IT projects is rarely straightforward. Part of the difficulty is that some benefits are intangible. For a proposed system that involves big data, real time analytics, or 3D printing, there may be no previous evidence of what sort of financial payback can be expected.
Legal and organizational feasibility. Are there legal, regulatory, or environmental reasons why the project cannot or should not be implemented? This analysis looks at the companys policies and politics, including impacts on power distribution and business relationships.
Behavioral feasibility. Behavioral feasibility considers human issues. All system development projects introduce change, and people generally resist change. Overt resistance from employees may take the form of sabotaging the new system (e.g., entering data incorrectly) or deriding the new system to anyone who will listen. Covert resistance typically occurs when employees simply do their jobs using their old methods.
Behavioral feasibility is concerned with assessing the skills and the training needed to use the new IS. In some organizations, a proposed system may require mathematical or linguistic skills beyond what the workforce currently possesses. In others, a workforce may simply need to improve their skills. Behavioral feasibility is as much about can they use it as it is about will they use it.
After the feasibility analysis, a Go/No-Go decision is reached. The project sponsor and project manager sign off on the decision. If it is a no-go decision, the project is put on the shelf until conditions are more favorable, or the project is discarded. If the decision is go, then the system development project proceeds.

5. Four conversion strategies are parallel, direct cut over, pilot, and phased.

In a parallel conversion, the old system and the new system operate simultaneously for a period of time. That is, both systems process the same data at the same time, and the outputs are compared. This type of conversion is the most expensive but least risky.

In a direct conversion, the old system is cut off and the new system is turned on at a certain point in time. This type of conversion is the least expensive, but it is the most risky if the new system does not work as planned.

A pilot conversion introduces the new system in one location to test it out. After the new system works properly, it is rolled out.

A phased conversion introduces components of the new system, such as individual modules, in stages. Each module is assessed, and, when it works properly, other modules are introduced until the entire new system is operational.

29 Article
DOI: 10.1111/j.1468-0394.2012.00630.x

Exploring the relationship between system development life
cycle and knowledge accumulation in Taiwans IT industry
Wen-Hsiang Lai and Hsin-Cheng Tsen
Feng Chia University 100, Wenhwa Rd., Seatwen, Taichung 40724, Taiwan
Email:[emailprotected]

Abstract: Many projects fail because the knowledge learned from them is obtained too late or insufficient (Koenig & Srikantaiah,
2004); knowledge in projects, knowledge about projects, and knowledge from projects are three types of knowledge that result from
project-based work (Love et al., 2005). This study explores the relationships between the system development life cycle (SDLC) of
project management, firm-level explicit knowledge of organizational knowledge accumulation (OKA), and implicit knowledge of employee
knowledge accumulation (EKA) with respect to knowledge accumulation (KA) and knowledge integration (KI). First, it analyzes the
competence of SDLC in Taiwans IT enterprises by adapting expert interviews, analytic hierarchy process (AHP), and fuzzy rule-based
theory. This reveals that system planning (SP) and system analysis (SA) are the most important SDLC phases. Second, based on the above
result, this study investigates how the effectiveness of SDLC (ESDLC) correlates with KI, OKA, and EKA. Results indicate that EKA and
OKA have obvious mutual influences, and that both show significant impact on ESDLC. Furthermore, KI has positive influence on EKA,
but negative influence on OKA.

Keywords: knowledge integration (KI), knowledge accumulation (KA), system development life cycle (SDLC), information technology
(IT)

1. Introduction

Since more and more enterprises are becoming aware of an
optimal balance of product standardization and customiza-
tion (Yan et al., 2005), enterprises have started using infor-
mation technology (IT) to run their businesses (Zhang &
Wang, 2006), and thus the development of IT is becoming
the driving force of economic growth and the basis of pro-
ductivity enhancement in enterprises. One viewpoint is that
the new era of IT requires faster, smaller, and smarter ma-
terials, devices, and software for human beings. The main
areas of Taiwans IT services industry are system integra-
tion (SI) and IT outsourcing. In 2008, Taiwans Market In-
telligence & Consulting (MIC) Institute indicated that the
production value of SI in Taiwans IT industry had reached
NTD 80.82 billion, and the production value of IT outsourc-
ing had reached NTD 14.98 billion. Successful SI and IT
outsourcing projects in Taiwan produce a virtuous cycle of
Taiwanese IT growth. However, Zarrella et al. (2005) indi-
cate that IT project failure is a widespread problem. Based
on Keil and Manns (1997) investigation, at least 30% of
IT projects reveal some project escalation; project escala-
tion results in large payoffs, long-term payoffs, high clos-
ing costs, and low salvage values for IT companies (Pan
et al., 2009). IT teams that adopt the system development
life cycle (SDLC) method often increase their project success
rates. SDLC provides careful examination of functional goals
and detailed guidelines for system development and system
implementation.

Bengston and Lesser (1998) indicate that enterprises usu-
ally obtain skills and knowledge during the informatization
of operational procedures, and that the systematization of
operational procedures involves an opportunity for knowl-
edge accumulation (KA). Therefore, the key to enterprise

competitiveness is the refinement of valuable organizational
memories (knowledge) from the current structure of oper-
ational procedures; firms can systematize their most conve-
nient and cost- and manpower-saving strategies. Enterprises
should conduct KA during the informatization of their op-
erational procedures in order to achieve effective project ex-
ecution and KA.

An enterprise that informatizes its internal operational
procedures must build an information system (IS). This study
is an early investigation exploring the relationship between
SDLC and KA in Taiwans IT Industry. It also reveals the
relationships between an enterprises KA and the informati-
zation of its operational procedures; these relationships can
be used to analyze the implicit knowledge activities that hap-
pen when an enterprise develops IS. In this study, Analytic
Hierarchy Process (AHP) is used to calculate weights for the
five phases of SDLC. Since AHP can evaluate weights only
by making pairwise comparisons within the five phases of
SDLC, this research employs a fuzzy logic inference system
(FLIS) to generate 3D fuzzy surfaces to analyze the rela-
tionships within those five phases. FLIS researchers often
make use of the Delphi method to collect opinions from
professionals and to generate a fuzzy logic gate for fuzzy
rule-based calculations (Perng et al., 2005; Hsu & Chen,
2007). To simplify the interview processes, the AHP weights
can be utilized in the formation of the fuzzy logic gate. As
Section 3.1 explains, 3D fuzzy surfaces enable clear anal-
ysis of growth-and-decline relations within the five phases
of SDLC. Furthermore, Section 3.2 shows how, after the
3D fuzzy surfaces have been obtained, a statistical method
is adapted to analyze the effectiveness of SDLC (ESDLC)
correlating with knowledge integration (KI), organizational
knowledge accumulation (OKA), and employee knowledge
accumulation (EKA).

C 2012 Wiley Publishing Ltd Expert Systems, May 2013, Vol. 30, No. 2 173

2. Literature review

Knowledge is an important asset for a firm; it provides the
capacity to formalize and leverage its intellectual assets as
to formal and informal structure, functions, and processes.
Tsai et al. (2010, p. 840) point out that a knowledge reposi-
tory system serves to provide the exchanging intermediaries
of explicit knowledge between knowledge contributors and
knowledge seekers to assist knowledge sharing of employ-
ees in the enterprise. Codification and personalization are
two kinds of strategies applied in the knowledge manage-
ment within firms; knowledge-intensive organizations should
pursue either codification or personalization as a dominant
strategy (80%) and use the other as a supporting strategy
(20%) (Hansen et al., 1999). Codification knowledge repre-
sents explicit knowledge, which involves not only converting
undocumented information into documented information,
but also making institutional knowledge visible, accessible,
and usable for the decision making of firms. Codification
strategy connects people by using the information stored in
database systems, and thus IT supports the storage of this
knowledge and its retrieval across the organization (Dun-
ford, 2000). Personalization knowledge characterizes the im-
plicit knowledge where the knowledge of a firm is stored
mainly in people, and the sharing channel relies heavily on
human interaction (Palmer & Platt, 2005). Personalization
strategy involves using interpersonal relationships to mobi-
lize and use personal knowledge (Polanyi, 1967). Fong and
Kwok (2009, p. 1348) indicate, knowledge management is
critical and beneficial as indicated by 64% at the project and
74% at the organization level. This study analyzes firm-level
knowledge in two aspects, namely, EKA and OKA. EKA has
to do with implicit knowledge, and OKA refers to explicit
knowledge.

Love et al. (2005) observe that knowledge in projects,
knowledge about projects, and knowledge from projects
are three types of knowledge that result from project-based
execution and management. Knowledge in projects refers
to the knowledge that resides in a project in the form of doc-
umentation, meeting repositories, discussions, and project
management systems. Knowledge about projects includes
project designing, analyzing, planning, implementing, and
controlling. Knowledge from projects is the knowledge
achieved from executing a project in the form of best prac-
tices, lessons learned, post-project reviews, or after-action
reviews. However, according to Papowss study, one-third
of knowledge management projects fail (Papows, 1999); in
some cases, the lessons learned are obtained too late or are
forgotten once the review is obtained at the end of a project
(Koenig & Srikantaiah, 2004).

2.1. SDLC

Harrington et al. (1995) suggest that since the computa-
tional support for concurrent engineering design consists of
the design issues of knowledge-based systems, it is essential
to provide the life-cycle perspective in recommending de-
sign alternatives. SDLC is one of many well-known phase
models. It includes an overall process for developing, im-
plementing, and retrieving ISs through phases of initiation,
analysis, design, implementation, and maintenance. There
are many different SDLC models and methodologies; the

Figure 1: Five phases of system development life cycle
(SDLC) vs. knowledge accumulation.

typical method consists of a series of defined steps or phases.
SDLC is a conceptual model used in project management to
develop large-scale, functional business IT systems. SDLC
in IS activities revolves around heavy data processing and
number-crunching routines (Elliott, 2004); it leads to repeat-
able, high-quality results, and decreases project development
costs. In the context of IT, SDLC refers to a creative IS devel-
opment process; SDLC in IT is an entire process of formal
and logical steps taken to develop software products. The op-
erational procedures within an enterprise can be viewed as
the IS inherent to the enterprise. The IS development lifecy-
cle can be generally divided into five phases; each phase has
a different set of priorities, and each of the phases consists of
structural knowledge1, which should usually be documented
for maximum efficiency. Within the SDLC model, the mile-
stones are considered as baselines, and the baselines are
critical to the iterative nature of the model (Blanchard & Fab-
rycky, 2006). In the software industry, the waterfall model
is a traditional structured design technique based on SDLC;
however, Yamamichi et al. note, this conventional design
technique has limitations with respect to the transference of
technology and quality evaluation (Yamamichi et al., 1998,
p. 55). Also, because knowledge is widely used in a multitude
of applications within various domains (Srihari & Westby,
1992), and because a knowledge source operates on some in-
put data and builds the capability to transfer information as
new outputs (Wu et al., 2000), it is essential to consider KA
within the SDLC phases of IT projects. Figure 1 shows the
five phases of SDLC vs. KA. Table 1 contains explanations
of the five SDLC phases.

2.2. KA between firms and employees

Knowledge is an invisible but valuable asset; many firms
find it hard to make practical use of their knowledge as-
sets. Knowledge ages fast and can be rapidly upgraded. The
core issues of knowledge management are to obtain valuable
knowledge and to accumulate enterprise-specific knowledge.

1Dienes and Scott (2005, p.339) state, structural knowledge might con-
sist of knowledge of particular items, knowledge of fragments of items,
knowledge of other types of rules, or knowledge embedded in connection-
ist weights.

174 Expert Systems, May 2013, Vol. 30, No. 2 C 2012 Wiley Publishing Ltd

Table 1: Descriptions of five system development life cycle (SDLC) phases

Period Abbreviation Explanation Structural
knowledge

System planning SP SP involves setting goals, defining targ

Related Questions:

Related questions