Unit-1
The Software Problem
The cost of implementing a system is the cost of the resources used for the system, which are the manpower, hardware, software, and other support resources in the case of software. The manpower aspect is usually prevalent, as the production of software is mostly labor-intensive and the cost of computer systems is now very limited.
The cost of the software project is also calculated in terms of person-months, i.e. the cost is considered to be the total amount of person-months spent on the project. In many projects, schedule is a significant factor. Business patterns dictate that a product should be reduced in time to market; that is, the cycle time from design to delivery should be minimal.
While the need for high quality differentiates software for industrial strength from others, other major driving factors for such software are cost and schedule. There are three fundamental forces at play in the industrial-strength software domain: cost, schedule, and efficiency. The software should be developed at a reasonable rate, within a reasonable period of time, and of good quality. A software project is often guided and defined by these three parameters.
Despite the reality that software development is highly labor intensive, industrial-strength software is very costly. Let us consider the current state of practice in the industry to get an idea of the costs involved. Code lines (LOC) or thousands of code lines (KLOC) delivered are by far the industry's most widely used indicator of software size.
Since the manpower employed is the key cost of creating software, the cost of developing software is normally calculated in terms of individual months of effort expended on production. And productivity in the industry is often measured in terms of LOC (or KLOC) per person per month.
Schedule
Another major element in many projects is schedule. Business trends dictate that a product's time to market should be reduced; that is, there should be little cycle time from idea to delivery. This means that it needs to be built faster and within the time defined for software. The history of software, sadly, is full of cases where programmes have been significantly late.
Quality
Besides cost and schedule, quality is the other major factor driving software engineering. Quality is one of the key mantras today, and company strategies are built around it. Unfortunately, there have been a great deal of cases of programme unreliability. The software sometimes does not do what it is supposed to do or does something it is not supposed to do. Clearly, another basic aim of software engineering is to create high-quality software. However, though cost is generally well understood, the definition of efficiency requires further elaboration in the context of software.
|
Fig 1: Software quality attributes
We may describe these attributes as follows:
● Functionality: The ability to provide functions that, when the programme is used, fulfil specified and implied needs.
● Reliability: The capacity to provide service that is failure-free.
● Usability: The desire to be remembered, taught, and used.
● Efficiency: The ability to provide sufficient results compared to the amount of resources that are used.
● Maintainability: For the purpose of making corrections, adjustments, or adaptation, the capacity to be changed.
● Portability: The ability to adjust to various defined conditions without the implementation of measures or means other than those included in the product for this reason.
Key takeaway:
- The cost of implementing a system is the cost of the resources used for the system, which are the manpower, hardware, software, and other support resources in the case of software.
- Quality is one of the key mantras today, and company strategies are built around it.
- Different projects may emphasis different qualities with multiple dimensions of quality, and a global single quality number is not feasible.
Although cost, schedule, and quality are the key driving forces for a project in our problem domain (of software for industry strength), there are some other problem domain characteristics that also affect the solution approaches used. We concentrate on two such features: scale and change
Scale
The majority of software systems with industrial strength appear to be massive and complex, requiring tens of thousands of lines of code. Sizes are given in an illustration of some of the well-known software products to illustrate this point. Consider the issue of counting individuals in a room versus taking a nation's census. Both are counting concerns in nature. But the techniques used to count individuals in a space just won't work. Taking a census. In order to perform a census, a different set of approaches will have to be used, and the census issue will require far more administration, coordination, and validation, in addition to counting.
Similarly, when software of a few hundred thousand lines has to be developed, methods that one can use to create programmes of a few hundred lines cannot be expected to operate. To build large-scale applications, a particular set of approaches must be used.
The use of engineering and project management includes every software project. In small ventures, it is possible to use informal approaches for creation and management.
In other words, to execute a project effectively, a suitable method for The system must be used for engineering and the project must be closely regulated to ensure that cost, schedule and quality are monitored. Large scale is a key feature of the problem domain and instruments and techniques that have the potential to construct large software systems should be included in the solution approaches.
|
Fig 2: The problem of scale
Change
Change is another aspect of the problem domain that must be addressed by development approaches. As the full set of system specifications is typically not known (often not known at the beginning of the project) or specified, as indicated,
Additional criteria are defined for development proceeds and time passes, which need to be implemented into the software being developed.
This need for modifications demands that development methods accept and effectively tolerate change. Change requests can be very detrimental to a project, which can consume up to 30 to 40 percent of the construction cost if not managed properly.
Overall, when the environment changes faster, software, even when under development, needs to change faster. Therefore, changes in specifications are a function of the problem domain. Approaches that do not embrace and tolerate change in today's environment They can overcome only those few issues that are resistant to reform. They are of little use.
Software has to be updated even after it has been deployed, as discussed above. Although changes in software during maintenance have historically been distinct from changes that occur during development, these lines are blurring, as the changes in each of these cases are essentially identical, due to certain changes in the specifications or due to some bugs that need to be removed, existing source code needs to be modified.
Key takeaway:
- Change is another aspect of the problem domain that must be addressed by development approaches.
- The majority of software systems with industrial strength appear to be massive and complex, requiring tens of thousands of lines of code.
It is important to go through a series of predictable steps as you work to create a product or system - a road map that helps you produce a timely, high-quality result.
A " software process" is called the road map that you follow.
Technical definition:
The software process is a structure for the operations, activities and tasks needed to create high-quality software.
The term software specifies to the set of computer programs, procedures and
associated documents (Flowcharts, manuals, etc.) that describe the program and
how they are to be used.
A software process is the set of activities and associated outcome that produce a
software product. Software engineers mostly carry out these activities. These are
four key process activities, which are common to all software processes.
These activities are:
1. Software specifications: The functionality of the software and constraints on
its operation must be defined.
2. Software development: The software to meet the requirement must be
Produced.
3. Software validation: The software must be validated to ensure that it does
what the customer wants.
4. Software evolution: The software must evolve to meet changing client
needs.
Key takeaway:
- A software process is the set of activities and associated outcome that produce a software product.
- The software process is a structure for the operations, activities and tasks needed to create high-quality software.
A method is the sequence of steps taken to achieve a goal. Since several different objectives can have to be met during software development, several processes are required. Many of these do not involve software engineering, but they do influence the development of software. This may be called processes that are non-software. All examples of processes that fall under this include business processes, social processes, and training processes. Such procedures often influence the function of software development, but are outside the reach of software engineering.
The software process is collectively called the processes that deal with the technological and management problems of software creation. As a software project would have to design a solution and handle the project properly, there are obviously two key components in a software process: a process of creation and a process of project management.
The engineering activities that need to be conducted are specified in the development process, while the management process determines how to prepare and monitor these activities so that cost, schedule, quality and other goals are met. Efficient processes of growth and project management are the key to achieving the goals of supplying the required software that meets the needs of the customer, while maintaining high efficiency and quality.
There are several goods created during the project that usually consist of several objects (for example, the final source code may be composed of many source files). As the project continues, these things keep changing, making several versions on the way. As development processes usually do not concentrate on evolution and improvements, another mechanism called the software configuration control process is also used to manage them.
These three constituent processes concentrate on the projects and the goods and, since their primary objective is to deliver the desired product, may be considered to include the product engineering processes. If it is possible to interpret the software process as a static object, then these three component processes would be enough. A software process, however, is itself a dynamic object, as it needs to evolve in order to adapt to our increased understanding of software development and the availability of new technologies and resources. Because of this, a method for handling the software process is needed.
Improving the software process is the basic aim of the process management process.
By change, we mean that the process's capacity to produce quality products at low costs is enhanced. The current software process is studied for this, mostly by reviewing the projects that have been performed using the system.
The process management process deals with the whole process of understanding the existing process, evaluating its properties, deciding how to improve, and then influencing the change. Not only in the type of activities carried out in them, but usually also in the individuals who conduct the activities defined by the process, these component processes are distinct.
In a typical project, programmers, designers, testers, etc. carry out development activities; project management process activities are carried out by project management; configuration control process activities are carried out by a community commonly referred to as the configuration controller; and process management activities are carried out by the software engineering process group (SEPG).
|
Fig 3: software processes
Key takeaway:
- The software process is collectively called the processes that deal with the technological and management problems of software creation.
- A method is the sequence of steps taken to achieve a goal.
- The software process is collectively called the processes that deal with the technological and management problems of software creation.
In the life cycle of software development, different models are planned and described. These models are called Process Models for Software Development.
The software development process model is chosen for development on the basis of project motivation.
The various process models for software development are as follows:
1) Waterfall model
● The model of the waterfall is the classic model or the oldest model and is known as the model's mother. It is commonly used in government projects and in many business projects that are critical.
● The 'linear sequential model' or 'classic life cycle model' is often referred to as the waterfall model.
● In this model, before the beginning of the next step, each phase is implemented completely. Therefore, the stages in the waterfall model do not overlap.
● For small ventures, this model is used.
● Feedback is taken after each step of this model to ensure that the project is on the right direction.
● Only after the production is completed does the testing component start.
|
Fig 4: waterfall model
Usage:
The customer has very specific documented specifications for projects that do not rely on modifying the requirements, such as projects prompted by a request for proposals (RFPs).
2) V model
● The Verification and Validation model is known as the V model.
● This model is an extension of the model for the waterfall.
● Processes are executed sequentially during the life cycle of the V-shaped model.
● Before the execution of the next stage starts, each stage completes its execution.
|
Fig 5: V - shaped model
Usage:
Clearly defined and established software specifications
Technologies and instruments for software production are well-known.
3) Iterative & Incremental model
● It is designed to overcome the shortcomings of the waterfall model.
● It begins with an initial schedule and ends with the cyclic interactions being deployed in between.
● The fundamental idea behind this method is to develop a system through repeated cycles (iterative) and at a time (incremental) in smaller portions, enabling software developers to take advantage of what was learned during the development of earlier parts or system versions.
● It may consist of mini waterfalls or a model mini V-Shaped.
|
Fig 6: iterative & incremental model
Usage:
It is used in shrink-wrap and large system applications that incorporate small phases or segments. It can also be used in a system with separate components, such as an ERP system.
4) Big-Bang model
● The SDLC(Software Development Life Cycle) model in which no specific process is followed is Big-Bang.
● Generally, for small projects in which the development teams are small, this model is used. For academic projects, it is particularly useful.
● This model requires a bit of planning and does not follow formal growth.
● The creation of this model starts with the necessary money and efforts as an input.
● The output of this model is software developed that may or may not be in accordance with the client's requirements.
|
Fig 7: big-bang model
5) Code-and-fix model
● One step forward from the Big-Bang model is the code and fix model. The product that must be tested prior to release is identified.
● The testing team discovers the bugs and then sends the software back for repair. Developers complete some coding to deliver the fixes and send the software for testing again. This process is repeated until, at an acceptable level, the bugs are found in it.
|
Fig 8: code & fix model
6) Spiral model
● In an effort to combine the benefits of top-down and bottom-up concepts, it combines aspects of both design and prototyping-in-stages.
● The characteristics of the prototyping model and the waterfall model are combined in this model of development.
● For large, costly, and complicated projects, the spiral model is favored.
● This model uses many of the same phases as the waterfall model, separated by planning, risk evaluation, and the construction of prototypes and simulations, in essentially the same order.
|
Fig 9: spiral model
Usage:
It is used in large applications and systems in which small phases or segments are built-in.
7) Agile model
It is based on iterative and incremental growth, where requirements and solutions evolve through cross-functional team collaboration.
Usage:
It can be used for any kind of project, but the customer needs more engagement and to be interactive. We can also use it when, in less than three weeks, the customer needs to have some functional requirements ready and the requirements are not clear enough. This will allow software to be more valuable and workable early on, which will also increase customer satisfaction.
|
Fig 10: agile model
Key takeaway:
- The software development process model is chosen for development on the basis of project motivation.
- The model of the waterfall is the classic model or the oldest model and is known as the model's mother.
- The Verification and Validation model is known as the V model.
- The SDLC(Software Development Life Cycle) model in which no specific process is followed is Big-Bang.
- For large, costly, and complicated projects, the spiral model is favored.
Every project involves a set of processes to bring it to life, whether it is building a building, releasing an app, or carrying out a marketing campaign. Regardless of the sector or the type of deliverable, these procedures are very reliable. So what are these mechanisms of project management, and what do they consist of?
"The Project Management Body of Knowledge Guide (PMBOK Guide) breaks down the overall project management process into five phases, or "process groups."
Traditionally, these process groups are defined as:
- Initiation
The project is conceptualized at this stage and viability is decided. Some tasks that should be carried out during this phase, according to the SME Toolkit, include defining the project objective; defining the scope of the project; identifying the project manager and key stakeholders; identifying possible risks; and creating an approximate budget and timetable.
These two documents are produced to market the work to stakeholders or supporters before the project is accepted or rejected:
● Business case: This is where you explain the need for the project, which involves the review of investment returns.
● Feasibility study: You need to decide what the aims of the project are, the timetable for completion, and how much it will cost the whole undertaking. You also understand what equipment would be needed to achieve the project, and whether it makes financial and business sense.
- Planning
Next, from ideation to completion, the project manager will create a plan to direct the whole project. This blueprint will map the scope of the project; the resources needed to produce the deliverables; the expected time and financial commitments; the communication strategy to ensure that stakeholders are kept up-to-date and involved; the implementation plan; and the continued maintenance proposal.
- Execution
The project manager will perform the procurement needed for the project and staff the team at this time. In addition, effective management of the team members on the ground requires the implementation of the project goals.
It is the duty of PMs to delegate and supervise the project work while maintaining good ties with all team members and keeping the whole project on schedule and on budget. Therefore, the PM must be exceptionally coordinated and an outstanding leader. That's because team issues and any challenges that occur along the way would need to be resolved, requiring regular and transparent contact with all members of the team and stakeholders.
- Monitor & Control
Project managers will closely measure the progress of the project within this phase category to ensure that it is properly established. Documentation can be used, such as the compilation of data and verbal and written status reports. Monitoring and monitoring is closely linked to the planning of programmes. Although preparation decides what to do, monitoring and control determines how well it has been achieved," SME Toolkit explains." "In order to keep the project on track, monitoring will detect any necessary corrective action or change in the project."
- Closing
If the project deliverables have been created, the closing phase group takes place and the stakeholders verify and approve them. The project manager will close contracts with vendors, external suppliers, contractors, and other third-party suppliers during this process. All documents will be archived and there will be a final project report produced. In addition, the final component of the project plan, the troubleshooting and repair plan, will begin to take place.
Key takeaway:
- Initiation is where all programmes begin. As well as its viability, the importance of the project is calculated.
- What services are required, funding and supplies will be included in the project plan.
- All aspects of the project must be tracked and changed when appropriate to ensure that the project plan is revised.
- Once the project objectives and priorities have been accomplished, the project is not finished. It is being closed in the last phase of the project.
References:
- Software Engineering: A precise Approach – Pankaj Jalote (Wiley India)
2. Fundamentals of Software Engineering – Rajib Mall (3rd Edition)( PHI)
3. Software Engineering – Concepts & Practices –Ugrasen Suman (CenageLearning)
