Unit - 1
Overview of Project Management
Software project management (SPM) is a systematic approach to planning and directing software development initiatives. Software projects are planned, implemented, monitored, and controlled as part of project management.
The art and science of organizing and supervising software projects is known as software project management. It is a sub-discipline of software project management that deals with the planning, implementation, monitoring, and control of software projects.
It is a method of organizing, assigning, and scheduling resources in order to create computer software that meets criteria.
The client and the developers need to know the project's length, duration, and cost in software project management.
Need of Software Project Management
Software is a digital product that does not have a physical form. Software development is a relatively new field, with minimal expertise in creating software products. The majority of software solutions are customized to meet the needs of the client. The most important is that underlying technology evolves at such a quick pace that experience gained from one product may not be applicable to another. Because such economic and environmental restrictions raise the risk of software development, it is critical to effectively manage software projects.
It is vital for an organization to create a high-quality product while staying within the client's budgetary constraints and completing the project on time. As a result, software project management is required to take into account user needs as well as budget and schedule restrictions.
For software projects, the graphic above depicts triple limitations. It is an important component of software development to create a high-quality product while staying within the price constraints of the client and completing the project on time. This triple constrain triangle may be influenced by a number of internal and external factors. Any one of three factors can have a significant impact on the other two.
As a result, software project management is critical for incorporating user needs as well as budget and time restrictions.
Advantages of Software Project Management
● It aids in software development planning.
● Software development is made simple to implement.
● Software project management includes issues such as monitoring and regulating.
● Overall, it reduces the amount of time and money spent on software development.
Key takeaway
Software project management (SPM) is a systematic approach to planning and directing software development initiatives. Software projects are planned, implemented, monitored, and controlled as part of project management.
Project Manager
A project manager is a figure who is in charge of a project's entire planning, design, execution, monitoring, control, and closure. A project manager plays a crucial role in the successful completion of projects.
A project manager is a character who is in charge of making major and minor project choices. The project manager is in charge of managing risk and reducing uncertainty. Every action made by the project manager must benefit the project in some way.
Role of a Project Manager:
1. Leader: A project manager is responsible for leading his team and providing guidance so that everyone understands what is expected of them.
2. Medium: Between his clients and his team, the project manager serves as a conduit. He is responsible for coordinating and transferring all pertinent information from clients to his team, as well as reporting to senior management.
3. Mentor: He should be there to lead his team through each phase and ensure that they are connected. He makes a suggestion to his colleagues and directs them in the appropriate direction.
Responsibilities of a Project Manager:
● Risks and issues must be managed.
● Create a project team and assign duties to various members of the team.
● Planning and sequencing of activities.
● Progress is being tracked and reported on.
● To deal with the circumstances, the project plan was changed.
Project Manager Activity
Software project management entails a variety of duties, such as project planning, product scope determination, cost estimation in various forms, job scheduling, and so on.
The list of activities are as follows:
- Project planning and Tracking - It is a collection of operations, or a task, that must be completed prior to the start of product manufacturing.
- Project Resource Management - All of the pieces in software development are referred to as project resources. Human resources, productivity tools, and libraries are all examples.
The following are examples of resource management:
○ Create a project team and assign each team member duties.
○ The project plan is used to develop a resource plan.
○ Resource reorganization.
● Scope Management - It specifies the project's scope. Scope management is critical since it establishes what will and will not be done. Scope Management defines the project as a set of limited and measurable tasks that can be easily documented and thus avoid cost and time overruns.
● Estimation Management - This is not just about cost estimation; when we begin to develop software, we must first determine its size (line of code), effort, time, and cost.
When it comes to size, the line of code is determined by the user's or software's needs.
If we're talking about effort, we need to know the size of the software, because we can rapidly estimate the size of the team needed to create it based on the size.
When it comes to time, the time required to develop software can be easily determined when the size and effort required are evaluated.
And when we talk about cost, we're talking about everything:
● Size of software
● Quality
● Hardware
● Communication
● Training
● Additional Software and tools
● Skilled manpower
● Project Risk Management - Risk management encompasses all project-related operations such as identifying, assessing, and planning for predictable and unanticipated risks.
Several points highlight the project's risks:
The project's experienced team leaves, and a new team takes its place.
○ Requirements change.
○ Technology and the environment are both changing.
○ Competition in the marketplace.
● Scheduling Management - In software, scheduling management refers to all of the tasks that must be completed in the sequence stated and within the time allotted for each action. Project managers establish several tasks and prioritize them based on a variety of factors.
It is required for scheduling -
● Compile a list of several tasks and connect them.
● Time is divided into units.
● For each job, assign the appropriate amount of work units.
● Calculate the total time spent from beginning to end.
● Dividing the project into modules is a good idea.
● Project Communication Management - The success of the initiative hinges on effective communication. It serves as a link between the client, the organization, the team members, and other project stakeholders such as hardware suppliers.
Communication is crucial throughout the process, from planning to completion. Communication must be clear and understandable at all times. Miscommunication might lead to a major project blunder.
● Configuration Management - Controlling changes in software, such as requirements, design, and development, is what configuration management is all about.
The main goal is to boost production while reducing errors.
The following are some of the reasons why configuration management is necessary:
● Several people work on software that is updated on a regular basis.
● Assist in the development of supplier coordination.
● Changes in demand, budget, and schedule must be accommodated.
● Software should be able to run on a variety of platforms.
Tasks perform in Configuration management:
● Identification
● Baseline
● Change Control
● Configuration Status Accounting
● Configuration Audits and Reviews
Stakeholders
Stakeholders are those who are interested in the result of your project. Members of a project team, project managers, executives, project sponsors, customers, and users are common examples. Stakeholders are people who will be impacted by your project at any stage during its life cycle, and their input can have a direct impact on the final result. To collaborate on a project, it's critical to practise strong stakeholder management and communicate frequently.
Types of stakeholders
In project management, there are two sorts of stakeholders: internal and external.
Internal stakeholders
These stakeholders are from within the building!!! Internal stakeholders are individuals or groups within a company, such as team members, managers, and executives.
External stakeholders
External stakeholders are, as you might expect, individuals or organizations who are not affiliated with the company. Customers, users, vendors, and investors are all included.
As you can see, project stakeholders aren't always on the project manager's side. Needless to say, this can add to the complexity, since you'll need to communicate with people at various levels of the organization, with diverse levels of engagement, influence, and interest.
The role of stakeholders in a software project
Individuals, groups, or organizations that are actively involved in a software project, have the ability to influence it owing to their position, and whose interests may be influenced by the project's success or failure are referred to as stakeholders. Stakeholders may have varying levels of duties and authority, which may shift over time as the software development lifecycle progresses.
End-users, for example, generally have an indirect impact on a project. Users who participate in MVP testing, on the other hand, may change their responsibilities and have a direct impact on future project development processes.
Competing stakeholder expectations can sometimes turn into a tense dispute. Stakeholder involvement, on the other hand, is one of the most effective tactics for achieving excellent project results and meeting your main business objectives.
There are two types of stakeholders in a software project: primary and secondary. This sorting aids in prioritizing the interests of project participants and improving decision-making. What are the key and secondary stakeholders in a software development project, and what role do they play in the project's evolution?
Why Are They Important?
It's a risky undertaking to ignore stakeholders. First and foremost, developers are working with an incomplete set of needs without their input. During the development process, unexpected needs are certain to arise. Scope creep occurs when a project expands beyond its original limitations as a result of these unexpected additions. The original time and budget constraints are pushed to the limit to accommodate the new requirements. This isn't always the case. To fulfill deadlines, it's much more likely that some features will be cut. Missed contributions have implications even when deadlines and budgets are met. Adoption is a significant risk. Employees don't always use software that is exactly what management desires.
They may already have more effective tools, or they may discover that the new programme lacks features they desire, or they may simply be unconvinced of the software's worth. Whatever the case may be, their lack of passion results in a squandered investment. This is especially true for smaller and more specialized groups, whose demands are frequently disregarded. There is room for additional criteria in development. Those, on the other hand, should be a response to ongoing input rather than a band-aid for a faulty discovery process.
Examples of stakeholders in a project
The sorts of stakeholders in project management that you may need to consider vary based on the type of project and industry, however here are a few examples of stakeholders in project management that you may need to consider:
● Project manager
● Team members
● Managers
● Resource managers
● Executives
● Senior management
● Company owners
● Investors
● Sponsors
● Financiers (the people, not the cakes)
● Suppliers
● Vendors
● Consultants
● Customers
Project communication
Effective communication is critical to a project's success. It bridges the gap between the client and the organization, as well as between team members and other project stakeholders such as hardware suppliers.
Oral and written communication are both acceptable methods of communication. The following steps may be included in the communication management process:
● Planning - This step entails identifying all project stakeholders and determining how they will communicate with one another. It also considers whether any new communication equipment is needed.
● Sharing - Following the determination of various components of planning, the manager concentrates on sharing accurate information with the appropriate person at the appropriate time. This keeps everyone participating in the project informed about its progress and status.
● Feedback - Project managers prepare status and performance reports using a variety of metrics and feedback mechanisms. This technique ensures that the project manager receives input from diverse stakeholders in the form of feedback.
● Closure - Administrative closure is explicitly notified at the end of each key event, the completion of a phase of the SDLC, or the end of the project itself to alert all stakeholders by email, hardcopy distribution, or other means of effective communication.
The team then moves on to the next phase or project after the closing.
The Project Management Institute, the world's biggest nonprofit group for project managers, defined the five phases of project management. PMI enlisted the help of over eighty experts to establish A Guide to the Project Management Book of Knowledge in order to standardize project management techniques. The association keeps the handbook up to date, and it comprises the core techniques that firms all over the world employ to get the best results.
By breaking down your efforts into these five project management phases, you can give them structure and break them down into a series of logical and achievable tasks.
● Initiating,
● Planning,
● Executing,
● Monitoring and Controlling,
● Closing.
Phase 1: Project initiating
This is where the project officially begins. Its main goal is to define the project in broad terms.
Typically, phase 1 begins with a business case. The goal is to ensure that the project is feasible and that it should be completed at all. If a company does feasibility testing, now is the optimal time to finish it.
During this phase, all project stakeholders will review the business case and determine whether or not to proceed with the project. If everyone is on board with starting the project, it's time to draft a project charter, also known as a project initiation document (PID). The project's goal and requirements, including business needs, the business case, and all stakeholders, are outlined in this paragraph. It's worth noting that the PID does not include the project's technical needs (which are determined in phase two).
Phase 2: Project planning
Once the project is approved, project managers will require a good project plan to guide their team, ensure that the project is completed on time, and under budget. A well-written project plan will guide you through the process of getting resources, gaining financing, and obtaining necessary components. The project plan directs the team's efforts to produce high-quality outputs, manage risk, get acceptance, communicate advantages to stakeholders, and manage suppliers.
The project plan also helps teams comprehend the project's cost, scope, and timeline by preparing them for any difficulties that may arise during the course of the project.
Because it focuses on defining the roadmap, the second phase is important to the project's success. Setting project objectives is usually the first step in this phase. Project managers can use a variety of ways to define goals, including SMART and CLEAR.
Phase 3: Project executing
This is the procedure for developing and completing project deliverables by the team. Meetings, status reports, development updates, and performance reports are all part of this phase, which is the most important component of any project.
This phase is usually preceded by a kickoff meeting at which all of the project's teams are briefed on their roles. The Project Manager must establish the team, assign resources, and carry out the project management plan throughout this phase.
The Project Manager's role is to direct and manage the project's execution by establishing tracking systems, allocating tasks, holding status meetings, updating the project schedule, and making changes to plans as needed.
Phase 4: Project monitoring and Controlling
The project's progress and team performance are measured in the fourth phase of project management. The goal here is to make sure that everything follows the project management strategy that was previously developed. Product managers utilize Key Performance Indicators to ensure that the project is moving in the right direction (KPIs). A Project Manager usually selects two to five KPIs.
Project managers, for example, need to know whether the project is on track and under budget, as well as whether it will satisfy stakeholder objectives. Determining whether the team is meeting certain task deliverables is another area of concern.
To keep the project's budget on track, the Project Manager will need to account for the cost of resources. It's also a good idea to think about the quantity and kind of issues that develop during the project, as well as how quickly the team handles them. Project Managers may need to alter resources or schedules at this phase to keep the project on track.
Phase 5: Project closing
The final phase depicts the project as it has been completed. Team members' efforts will be recognised by the Project Manager. Project managers frequently host a work event for everyone who contributed to the project to reward them for their efforts.
When the project is completed, the Project Managers convene a meeting known as a "postmortem" to assess what went well and identify the most critical faults. This type of lessons learned meeting is extremely beneficial to organizations since it allows for future project improvements.
Project managers still have a few things to accomplish after the project is concluded. It's a good idea to start by making a list of everything that hasn't been completed during the project and then working with the team to finish it. In addition, project managers are responsible for delivering the final project budget and preparing the final project report. Finally, they gather all of the project materials and deliverables in one location.
Key takeaway
By breaking down your efforts into these five project management phases, you can give them structure and break them down into a series of logical and achievable tasks.
A project's charter is a statement of the project's goals. This statement also outlines the project's specific goals, tasks, and responsibilities, as well as the primary stakeholders and the project manager's level of authority.
It serves as a roadmap for future projects and a key resource in the organization's knowledge management system.
The project charter is a brief document that includes a request for a new offering or a request for proposal. The Initiative for Policy Dialogue (IPD) and Customer Relationship Management both require this document as part of the project management process (CRM).
The Role of Project Charter
The duties of a Project Charter are as follows:
● It explains why the project is being undertaken.
● Outlines the project's goals as well as the challenges it faces.
● Offers solutions to the issue at hand.
● Identifies the project's primary stakeholders.
Elements in Project Charter
Because a project charter is a project planning tool targeted at resolving an issue or an opportunity, the factors listed below are critical to a successful charter project.
These major components must be addressed in order for a charter project to be successful:
● The project's identity.
● Time: the project's start date and completion date.
● Participants in the project.
● Goals and objectives have been outlined.
● The reason for carrying out a project charter, often known as a "business case."
● Describes a problem or an opportunity in detail.
● The estimated profit from the project.
● In terms of performance, these are the outcomes that could be expected.
● The date by which the objectives are projected to be completed.
● The participants' roles and obligations are well stated.
● Requirement for resources that will be required to meet the goals.
● Obstacles and hazards associated with the project
● Communication strategy that is well-informed and effective.
There are three most crucial and necessary factors that need to be elaborated on out of all of the above elements.
Benefits of Project Charter
The following are some of the most important advantages of a project charter:
● It enhances and facilitates positive customer connections.
● The Project Charter can also be used to help with project management.
● Communications between regional offices and headquarters can also be improved.
● Project sponsorship can also be obtained with the help of a project charter.
● Senior management functions are recognised in the Project Charter.
● Allows for advancement in the pursuit of industry best practises.
The project charter is not only a tool for planning projects, but it also serves as a communication and reference mechanism. A well-planned project with an efficient communication plan will almost certainly result in the project's success.
As a result, the Project Charter should be one of the most frequently cited papers in a project, and the Project Charter's content should be understood by the entire project team. This is an important aspect of any project's success.
Statement of work (SoW)
Work requirements and circumstances should be adequately documented when building or constructing large and complicated systems (such as an enterprise software system). A statement of work (SOW) is a document that outlines the tasks that must be completed under the terms of the contract.
Typically, the SOW is prepared in business-specific language that is explicit and definitive. This avoids any misunderstandings about terms and expectations.
The work needs for a specific project are covered by a SOW, which also addresses the performance and design criteria.
The SOW refers to the specific document where requirements are detailed or incorporated within a supplementary document.
The scope and working arrangements between two parties, often a client and a service provider, are defined by the SOW. As a result, SOW has legal significance.
Format of SOW
The formats of SOWs varies from one industry to the next. Some major parts of the SOW are universal, regardless of industry. The following are some of the most frequently addressed areas in a SOW:
1. Scope
This section provides a technical description of the task to be completed. If the system to be developed is a software system, this part specifies the hardware and software requirements, as well as the specific work to be done on the final system.
If there is anything that is 'out of scope,' it is noted under a relevant subheading.
2. Location
This section specifies the place where the work is performed. In addition, a description of human resources and how they function is provided.
3. Timelines
This establishes the time frame for the projects. It includes the time spent on development, warranty, and maintenance. The number of man days (total effort) necessary to finish the project is also indicated in addition to the calendar time.
4. Delivery schedule
The deliveries and their due dates are described in this section of the SOW.
5. Standards
This section defines the standards (internal and external). All delivery and work must adhere to the guidelines outlined in this section of the contract.
6. Acceptance Criteria
The basic standards for accepting deliverables are defined in this section. It also explains how acceptance criteria are determined.
7. Mode of contract and payments
When it comes to hiring a service provider, there are a variety of engagement models to choose from.
There are two separate contract structures in the software development domain: fixed bid and retainer.
The project cost is fixed in a fixed bid, and it is up to the service provider to optimize resource allocation to retain profit margins.
The client is unconcerned about the number of resources used as long as the deadline is met. The client pays for the quantity of resources allotted to the project in the retainer model.
Because the SOW is an integral aspect of the project, practically every senior member of the project team should be familiar with its terms and conditions. If delivery dates are missed, a penalty is sometimes imposed, especially in software development contracts. As a result, everyone should be aware of such stringent SOW terms.
Purpose of SOW
The fundamental objective of a SOW is to outline the client's and service provider's liabilities, responsibilities, and work agreements.
The scope of the engagement and the engagement's Key Performance Indicators (KPIs) will be defined in a well-written SOW.
As a result, the KPIs can be used to establish if the service provider has met the SOW's terms and can be used as a benchmark for future engagements.
The SOW comprises the information of the contractor's or service provider's effort's non-specifications requirements. When specifications are included, references to specific specification documents are made from the SOW.
Functional or non-functional requirements might be included in these specification documents.
Non-functional requirements detail other characteristics of the software, such as performance, security, maintainability, configuration management, and so on. Functional requirements (in a software system) define how the software should behave functionally, while non-functional requirements detail other characteristics of the software, such as performance, security, maintainability, configuration management, and so on.
Statement of Work Examples
An SOW can be divided into many categories. There are three primary categories, which can be summarized as follows.
- Design/Detail: When you write this SOW, you're basically telling the provider how you want the job done. What are the buyer's criteria for the supplier's process to be controlled? To ensure that you collect all of them, you might utilize a requirements gathering template. These project specifications can range from quality acceptance criteria to payment terms to material measurement. The buyer is held liable for the performance in this SOW because he is the one who is steering the project's course.
- Level of Effort/Time and Materials/Unit Rate: This is a nearly universal version that may be used for almost any project. It specifies both hourly service and the supplies required to complete the jobs. It's most common in short-term contracts.
- Performance Based: Project managers appreciate this SOW since it concentrates on the project's purpose, resources, and the expected quality level of deliverables. It does not, however, describe how the work is to be completed. This gives you a lot of flexibility in terms of how you get to your goal without having you to follow a set of steps.
Key takeaway
A project's charter is a statement of the project's goals. This statement also outlines the project's specific goals, tasks, and responsibilities, as well as the primary stakeholders and the project manager's level of authority.
The SOW refers to the specific document where requirements are detailed or incorporated within a supplementary document.
Software project planning is a work that must be completed before software development can begin. It's there to help with software development, but it doesn't entail any specific action that has anything to do with software production; rather, it's a collection of many procedures that help with software production.
Once a project is determined to be feasible, computer code project managers develop the project. Even before any development activity begins, project design is conducted and finalized. Following are the steps involved in project planning:
Estimating the project's later characteristics:
● Project size - What are the potential drawbacks in terms of the effort and time required to build the product?
● Cost - What percentage of the project's worth is it costing to develop?
● Duration - How long will it take for you to want complete development?
● Effort - What percentage of effort is required?
The accuracy of such estimations will determine the effectiveness of the next designing tasks.
● alternative resources and a planning force
● Plans for worker organization and staffing
● Identifying risks, analyzing them, and devising strategies to mitigate them.
● Various arrangements such as a quality assurance plan, configuration, management arrangement, and so on.
Several people contribute to the project's planning. Senior management and the project management team are among them. Senior management is in charge of hiring team members and providing the necessary resources for the project. Project managers and developers make up the project management team, which is in charge of planning, determining, and tracking the project's actions. The tasks completed by personnel involved in the software project are listed in the table.
Tasks of Individuals involved in Software Project
Senior Management | Project Management Team |
Approves the project, hires staff, and provides the necessary resources. Examines the project plan to ensure that it meets the company's goals. Resolves disagreements among team members. Consider potential project hazards so that necessary precautions can be taken to avoid them. | Examines the project plan and puts procedures in place to finish it.
Manages all aspects of the project.
Prepares plans for budgeting and resource allocation.
Assists in resource distribution, project management, and problem resolution, among other things.
Understands the project's goals and devises strategies to achieve them.
Spends enough time and effort to obtain the desired objectives.
Selects the project's methodologies and tools. |
Order of precedence for project planning activities
A project manager's many project-related estimates have already been mentioned. The figure below depicts the sequence in which critical project development activities are carried out. The first action is size estimate, which can be easily identified. Alternative estimations, such as the estimation of effort, cost, resource, and project length, are furthermore significant parts of project development.
Fig 1: Precedence ordering among planning activities
Sliding Window Planning
Because adherence to incorrect time and resource estimates results in schedule slippage, project planning requires extreme caution and attention. Client dissatisfaction and a negative impact on team morale will result from schedule delays. It may potentially result in project failure.
Project design, on the other hand, can be a tough task. Creating accurate blueprints, particularly for huge structures, is quite difficult. Because the correct parameters, the scope of the project, project personnel, and other factors may change over the course of the project, this is a part of the problem. To overcome this disadvantage, most project managers approach project design in stages.
Managers are protected from making large commitments too early by designing a project in stages. Window design is the term for this technique of staggered design. Beginning with an initial set up, the project is planned more precisely in consecutive development stages using the window technique.
At the start of a project, project managers receive only a smattering of information on the project's important aspects. As the project goes through different phases, its data base improves step by step. After each section is completed, the project managers will set up each subsequent section more precisely and with increasing levels of confidence.
Key takeaway
Software project planning is a work that must be completed before software development can begin. It's there to help with software development, but it doesn't entail any specific action that has anything to do with software production; rather, it's a collection of many procedures that help with software production.
A Work Breakdown Structure entails breaking down a huge, complex project into smaller, more manageable, and self-contained jobs. The Project name is used to label the root of this tree (structure). Each node is recursively divided into smaller sub-activities for the purpose of developing a work breakdown structure, until the activities become undividable and independent at the leaf level. It employs a Top-Down strategy.
Work Breakdown Structure is a method for breaking down large projects into smaller, more manageable jobs (WBS).
This strategy is typically used by project managers to make project execution easier. Larger projects are broken down into digestible portions of labour in WBS. These portions are simple to monitor and estimate.
When it comes to application, WBS is not limited to a single field. This methodology can be applied to any project management situation.
The following are some of the reasons why a project should have a work breakdown structure:
● Project organization that is both accurate and readable.
● The project team's responsibilities are assigned correctly.
● Marks the project's milestones and checkpoints.
● It aids in the estimation of cost, time, and risk.
● Make a visual representation of the project scope so that stakeholders may comprehend it better.
Construction of a WBS
The first step in creating a work breakdown structure is to identify the project's major deliverables.
The project managers and subject matter experts (SMEs) involved in the project are normally in charge of this crucial step. Following this, subject matter experts begin breaking down the high-level tasks into smaller chunks of labor.
One can split down the jobs into different levels of detail while breaking them down. A high-level task can be broken down into 10 sub-tasks, whereas a similar high-level task can be broken down into 20 sub-tasks.
As a result, there is no hard and fast rule for how a task should be broken down in WBS. Rather, the extent of breakdown is determined by the project's type and management style.
There are a few "rules" that can be used to determine the smallest work block. Nothing is broken down smaller than two weeks worth of labor under the "two weeks" guideline.
This signifies that the WBS's smallest assignment is at least two weeks long. Another rule that is employed while developing a WBS is the 8/80 rule. This rule states that no task should take less than 8 hours to complete and no task should take more than 80 hours to complete.
One can display their WBS in a variety of ways. To show the WBS, some people use a tree structure, while others use lists and tables. One of the simplest methods to portray a WBS is to outline it.
The following is an example of a work breakdown structure (WBS):
Fig 2: WBS
WBS has a number of design objectives. The following are some essential objectives:
● Bringing essential work initiatives to the attention of the public.
● Increasing the visibility of high-risk projects.
● Show the link between the activities and the deliverables.
● Task leaders must demonstrate unambiguous ownership.
Uses
● It enables accurate cost estimation for each activity.
● It enables for a more precise estimation of how long each action will take.
● It makes project management a breeze.
● It assists top management in properly organizing the project.
WBS Diagram
The project scope is graphically described in a WBS diagram. Typically, a visual item or a box at the top of the diagram depicts the complete project. There are other sub-components beneath the box.
These boxes represent the project's deliverables. There are sub-elements specified under each deliverable. These sub-elements represent the tasks that must be completed in order to meet the deliverables.
Although the majority of WBS diagrams are built using deliveries, some WBS are created using project phases. In most cases, information technology projects are well-suited to the WBS paradigm.
As a result, WBS is used in practically all information technology projects.
There is a specific goal for developing a WBS in addition to the usual application of WBS. WBS is the source of information for Gantt charts, a project management tool.
The Gantt chart is used to track the progress of WBS-derived tasks.
A sample WBS diagram is shown below:
Fig 3: WBS sample diagram
Key takeaway
A Work Breakdown Structure entails breaking down a huge, complex project into smaller, more manageable, and self-contained jobs. The Project name is used to label the root of this tree (structure).
A project is used by a manager to attain goals and projected results within a set schedule and budget. There are a variety of approaches to assist managers at every stage of a project, from inception to implementation to closure, regardless of which field or profession they work in. We will attempt to explore the most widely used project management approaches in this course.
A methodology is a framework that project managers use to develop, plan, implement, and achieve their project objectives. There are various project management approaches that can be used to benefit various projects.
For example, NASA uses a specific process to construct a space station, whereas the Navy uses a different methodology to construct submarines. As a result, various project management approaches exist to meet the needs of various projects across various business disciplines.
The most often utilized project management approaches in project management practices are as follows:
Adaptive Project Framework
The project scope is a variable in this methodology. In addition, the project's time and cost are also constants. As a result, during project execution, the project scope is altered in order to maximize the project's business value.
Agile Software Development
The agile software development process is used for projects that demand a lot of flexibility in terms of requirements. Agile's short-term delivery cycles (sprints), agile requirements, dynamic team culture, less stringent project control, and emphasis on real-time communication are all significant characteristics.
Crystal Methods
Project processes are assigned a low priority in the crystal technique. This strategy emphasizes on team communication, team member abilities, people, and interaction rather than processes. The agile category includes crystal methods.
Dynamic Systems Development Model (DSDM)
The Rapid Application Development (RAD) technique has been superseded by this one. This is another subset of agile software development technique that boasts about its training and documentation assistance. This strategy places a greater emphasis on active user participation throughout the project life cycle.
Extreme Programming (XP)
Extreme programming's major goal is to reduce the cost of requirement changes. Fine scale feedback, continuous process, common understanding, and programmer welfare are all emphasized in XP. There are no comprehensive requirements specifications or software architectures in Windows XP.
Feature Driven Development (FDD)
Simple and well-defined processes, quick iterative and feature-driven delivery cycles are more important in this methodology. In this project type, all planning and execution is based on the features.
Information Technology Infrastructure Library (ITIL)
This technique is a set of project management best practises. ITIL covers a wide range of project management topics, beginning with organizational management.
Joint Application Development (JAD)
This style emphasizes involving the client in the project tasks from the beginning. JAD sessions are held cooperatively between the project team and the client in order to obtain the client's input. These JAD sessions occur throughout the project life cycle.
Lean Development (LD)
The goal of lean development is to create software that is change-tolerant. The greatest priority in this strategy is to satisfy the customer. The staff is driven to give the customer the best possible value for their money.
Rapid Application Development (RAD)
This practice focuses on producing higher-quality items in a shorter amount of time. It employs the workshop method when obtaining needs. Prototyping is a technique for obtaining explicit requirements and reusing software components in order to reduce development time.
Internal communications of any kind are considered informal in this manner.
Scrum
This is an agile approach. The fundamental purpose of this system is to drastically increase team productivity by removing all conceivable obstacles. A Scrum master oversees Scrum initiatives.
Spiral
The extended waterfall model with prototyping is the spiral process. For major projects, this strategy is utilized instead of the waterfall paradigm.
Systems Development Life Cycle (SDLC)
This is a software development project's conceptual model. For the greatest results, this strategy allows you to combine two or more project management methodologies. SDLC also places a strong emphasis on documentation and has strict documentation rules.
Waterfall (Traditional)
For software development projects, this is the traditional model. This methodology has been in use for decades prior to the introduction of the new methodologies. The development lifecycle has fixed phases and linear timelines under this paradigm. This methodology is incapable of dealing with the present software development difficulties.
SDLC is a process used by the software industry to design, develop and test high quality software. SDLC is a framework defining tasks performed at each step in the software development process.
Within a software organization, the SDLC is a process that is followed for a software project. It is a detailed strategy that explains how to build, maintain, replace, and change or improve certain software. The life cycle is a mechanism for enhancing software quality and the development process as a whole.
A graphical illustration of the many steps of a typical SDLC can be found in the diagram below:
Fig 4: Development life cycle
SDLC process is divided into following stages
● Requirement gathering and analysis: In this stage the team members get detailed and precise requirements. This helps the company to calculate the risks involved and finalize the necessary timeline to finish the work and also to give quality assurance.
● Feasibility study: The next step is to define and document the software needs. This stage is completed with the help of SRS (Software Requirement Specification). It involves everything which should be designed and developed during the project life cycle.
● Design: In this stage, the system and software design documents are prepared as per the SRS document. This helps to define overall system architecture.
● Coding: In this stage, the developers start building systems by writing codes using chosen programming language.
● Testing: This phase includes the debugging process. All the flaws are detected here, documented and passed back to the developer to fix. This continues till all the flaws are removed.
● Deployment: When the program is finalized and has no issues, then it is ready to be launched for the end users
Software Development Life Cycle Models
● Waterfall Model
● Prototyping Model
● Evolutionary Model
● Spiral Model
● Iterative Enhancement Models
Waterfall Model
● It is a simplest model, which states that the phases are organized in a linear order.
● The model was originally proposed by Royce.
● The various phases in this model are
○ Feasibility Study – The main aim of the feasibility study activity is to determine whether it would be financially and technically feasible to develop the product. The feasibility study activity involves the analysis of the problem and collection of all relevant information relating to the product such as the different data items which would be input to the system, the processing required to be carried out on these data, the output data required to be produced by the system as well as various constraints on the behavior of the system.
● Requirement Analysis – The aim of the requirement analysis is to understand the exact requirements of the customer and to document them properly. The requirement analysis activity is begun by collecting all relevant data regarding the product to be developed from the users of the product and from the customer through interviews and discussions. During this activity, the user requirements are systematically organized into a software requirement specification (SRS) document. The important components of this document are the functional requirements, the nonfunctional requirements, and the goals of implementation. The SRS document is written in end-user terminology. This makes the SRS document understandable by the customer. After all, it is important that the SRS document be reviewed and approved by the customer.
● Design – This phase is concerned with
○ Identifying software components like functions, data streams and data stores.
○ Specifying software structure.
○ Maintaining a record of design decisions and providing.
○ There are two categories of Design:
● Architectural Design – It involves
● Identifying the software components.
● Decoupling and decomposing the software component into modules and conceptual data structures.
● Specifying the interconnection between the various blueprints for the implementation phase
● Detailed Design – It is concerned with details of the implementation procedures to process the algorithms, data structures and interaction between the modules and data structures. The various activities that this phase includes are
● Adaptation of existing code.
● Modification of existing algorithms.
● Design of data representation and
● Packaging of the software product.
This process is highly influenced by the programming language under which the implementation would be carried out. This stage is different from implementation.
● Implementation – It involves the translation of the design specifications into source code. It also involves activities like debugging, documentation and unit testing of the source code. In this stage various styles of programming can be followed like built-in and user defined data types, secure type checking, flexible scope rules, exception handling, concurrency control etc.
● Testing – It involves two kinds of activities
○ Integration Testing – It involves testing of integrating various modules and testing their overall performance due to their integration.
○ Acceptance Testing – It involves planning and execution of various types of tests in order to demonstrate that the implemented software system satisfies the requirements stated in the requirements document.
● Maintenance – In this phase the activities include
○ Corrective Maintenance – Correcting errors that were not discovered during the product development phase.
○ Perfective Maintenance – Improving the implementation of the system, and enhancing the functionalities of the system according to customer’s requirements.
○ Adaptive Maintenance – Adaptation of software to new processing environments.
Fig 5: Classical waterfall model
Prototyping Model
Fig 6: Prototyping model of software development
● Often, a customer defines a set of general objectives for software, but does not identify detailed input, processing, or output requirements. In other cases, the developer may be unsure of the efficiency of an algorithm, the adaptability of an operating system, or the form that human-machine interaction should take. In these and many other situations, a prototyping paradigm may offer the best approach.
● The various phases of this model are
● Listen to Customer: - This is the starting step, where the developer and customer together
● Define the overall objectives for the software,
● Identify the known requirements and
● The analyst then outlines those factors and requirements that are not visible normally but are mandatory from a development point of view.
● Build prototype: - After the identification of the problem a quick design is done which will cause the software to show the output that the customer wants. This quick design leads to the development of a prototype (a temporary working model).
● Customer test drives the prototype: - The customer runs and checks the prototype for its perfection. The prototype is evaluated by the customer and further improvements are made to the prototype unless the customer is satisfied.
● All the stages are repeated until the customer gets satisfied. When the final prototype is fully accepted by the customer then final development processes like proper coding for attaining maintainability, proper documentation, testing for robustness etc. are carried out. And finally the software is delivered to the customer.
Evolutionary Model
SDLC Evolutionary model builds the required product in several successive versions and hence is also known as successive version model or incremental model
● In this model the requirement is broken down into different functional units
● These functional units are known as modules
● The functionality improvements are done in these modules until the desired system is realized
● Each successive version is capable of performing more functions than the previous versions
Release of different evolutionary versions in SDLC:
Fig 7: Evolutionary development of a software product
● Each of the version will be released with some new functionalities added to the older one
● Here B will have more functionality than A, but will exhibit less capability than C
● As the system is viewed to be developed in incremental way so it is also termed as incremental model of development
Fig 8: Evolutionary model of software development
Types of project for which it is suitable:
● The evolutionary model is basically useful for very large products.
● Rather than waiting for the full product, the customer prefers to receive the product in increments so that he can start using them.
Spiral Model
● Evolutionary software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model.
● It provides the potential for rapid development of incremental versions of the software.
● Using the spiral model, software is developed in a series of incremental releases. During early iterations, the incremental release might be a paper model or prototype. During later iterations, increasingly more complete versions of the engineered system are produced.
● A spiral model is divided into a number of framework activities, also called task regions.
● There are six task regions.
● Customer communication—tasks required to establish effective communication between developer and customer.
● Planning—tasks required to define resources, timelines, and other project related information.
● Risk analysis—tasks required to assess both technical and management risks.
● Engineering—tasks required to build one or more representations of the application.
● Construction and release—tasks required to construct, test, install, and provide user support (e.g., documentation and training).
● Customer evaluation—tasks required to obtain customer feedback based on evaluation of the software representations created during the engineering stage and implemented during the installation stage.
Fig 9: Spiral model of software development
Iterative Enhancement Models
The iterative enhancement model, also known as the incremental model, incorporates the functionality of the waterfall model in an iterative manner. The waterfall model completes each step of software development, while the incremental model has phases that are similar to the linear sequential model and prototyping is iterative.
The project is divided into small subsets known as increments, which are introduced one at a time during the implementation process. This model has many stages, each of which generates an increment.These increments are defined at the start of the development phase, and each increment goes through the entire process from collecting specifications to delivering the product.
The basic concept behind this model is to begin with specifications and iteratively improve them before the final software is implemented. In addition, similar to prototyping, the increment generates input from the consumer by defining the software's specifications. This method is advantageous since it simplifies the software development process because smaller steps are simpler to incorporate than the entire framework.
Each stage of the incremental model introduces a new feature to the product before moving on to the next. The first increment is commonly referred to as a core product, and it is used by the consumer to conduct a thorough assessment. As a result of this procedure, a schedule for the next increment is established.
This strategy specifies how the product will be modified (features or functions) in order to meet consumer needs. The iteration process continues until the program is fully developed, which involves delivering increments to the customer.
The increments lead to implementations, which are evaluated in order to monitor the product's development.
Fig 10: Iterative enhancement model
A Generic model
The method is defined as a set of tasks, activities and tasks performed when a work product is to be produced. The acts and tasks of each of these activities are based on a structure or model that determines their relationship with the process and with each other.
A process model (also termed as software life cycle model) is a pictorial and diagrammatic representation of the software life cycle. A life cycle model represents
All the methods required to make a software product transit through its life cycle stages. It also captures the structure in which these methods are to be undertaken.
The software process is depicted schematically, with a collection of software engineering activities populating each framework activity.
A task set that defines the work tasks to be completed is defined by each software engineering activity.
The working products to be made, the points of quality assurance that will be needed, and the milestones to be used to demonstrate progress.
A generic system of process work for software engineering framework tasks -
● Communication
● Planning
● Modeling
● construction
● Deployment
Five application activities for communication, planning, modeling, construction, and deployment describe a common process framework for software engineering. In addition, a range of umbrella practices are implemented throughout the process: project monitoring and tracking, risk management, quality assurance, configuration management, technical reviews, and others. (called process flow)
Fig 11: generic process model
Communication
We communicate with clients and end-users at this step.
● We talk to the users about the project's requirements.
● Users provide feedback on the project. We come up with alternative suggestions if any adjustments are tough to accomplish.
Planning
We plan the steps for project development at this step. Following the conclusion of the final debate, we present a report on the project.
● In the software development process, planning is crucial.
● We talk about the project's potential hazards.
Modelling
We develop a model in this step to comprehend the project in the real world. All of the developers are shown the model. If any changes are necessary, we will make them in this stage.
● To gain a better grasp of the project, we create a practical model.
Construction
To develop the final product, we follow a procedure in this step.
● Code generation and testing are two parts of the construction process.
● The coding section uses an appropriate programming language to accomplish the design details.
● Testing is used to determine whether the coding flow is correct.
● Testing ensures that the programme produces the expected results.
Deployment
We present the project to the clients for evaluation and add any missing needs during this step.
● Delivering the product to the consumer and receiving feedback is what the deployment stage entails.
● If the customer requests some changes or extra capabilities, then a change is required to increase the software's quality.
Key takeaway
SDLC is a process used by the software industry to design, develop and test high quality software. SDLC is a framework defining tasks performed at each step in the software development process.
References:
- Roger S Pressman, Bruce R Maxim, “Software Engineering: A Practitioner’s Approach”, Kindle Edition, 2014.
- Ian Sommerville,” Software engineering”, Addison Wesley Longman, 2014.
- Software Project Management by Edwin Bennatan.
- Software Project Management by S.A. Kelkar.
