International Journal of Advanced Engineering Research and Science (IJAERS) [Vol -5, Issue-7, July- 2018]

https://dx.doi.org/10.22161/ijaers.5.7.21 ISSN: 2349-6495(P) | 2456-1908(O)

A Case Study on Identifying Software

Development Lifecycle and Process Framework
N. Devadiga
Abstract—This paper analyzes and determines which interchangeable, and projects were carried out without
software development lifecycle and process framework formal requirements documentation.
would be appropriate in the following case studies: Microsoft’s release strategy: Microsoft’s preferred
Microsoft office business unit, Denver Baggage, Avionics strategy was to deliver the product in many small releases
development, and Department of Transportation. The with short durations.
analysis for decision takes into consideration the Time constraint: The initial project was scheduled to be
stakeholders involved, the targeted audience, technology, delivered in one year.
business drivers, culture, time/schedule, resources, scope, Focus on programming: Microsoft’s projects at that time
and quality. relied heavily on programming aka build and demonstrate
Keywords—Software process, SDLC, Software model. It had always worked for them in the past.
framework. Developers and managers were not very concerned with
the software architecture or proces s methodologies.
I. INTRODUCTION Small team sizes: Development team size was typically
Technology is taking over the world at a rapid pace. With limited to 10 people.
the exponential growth of technology across diverse Unclear requirements: The requirements for the project
industries, software solutions have become essential in were not well defined. Microsoft wanted to add as many
every facet of the business. Because of the size and innovative features in the word processor, without
complexity of current software, there is a need to have a defining the project scope.
guiding process for development. However, with such Based on the above factors and as per [2] an agile process
diverse applications of software, there is a need to like Extreme Programming (XP) [14] would be a better fit
determine the appropriate process in the context of the for the OBU project. Below are potential reasons as to
situation. This paper investigates the following four case why extreme programming would serve the project better:
studies. Time criticality / Small releases: The primary focus of
Microsoft was to release the product to market as soon as
II. CASE STUDY: MICROSOFT OFFICE possible. With XP, it could be achieved by releasing an
BUSINESS UNIT (OBU) early version of the software and then incrementally
Microsoft released Word for Windows word processor in adding functionalities to it with later releases. Such
1989, after five years of development. The product incremental deployments are not feasible with traditional
received significant acclaim, and the sales concluded software processes like Rational Unified Process (RUP)
higher than Microsoft’s projections, however, the project [11], due to its monolithic development style. With Agile,
faced several project management issues in its execution the product can be built incrementally; particularly with
[1]. The project had issues ranging from ill-defined Extreme Programming (XP) process, a simplistic model
requirements, lack of planning, inadequate project of the system is released to production and newer versions
management, and random role assignment [1]. Most of are released in short cycles.
Microsoft’s products at that time were among the best Undefined requirements: Since the requirements were
available products on the market. Though the product was unclear and volatile, it makes sense to choose an agile
built in Microsoft’s standard style, Office Business Unit process that could quickly respond to changes.
project needed a structure - a process framework to guide Code-centric development: The nature of the project
the development. suggests that it was going to be code intensive (a word
Following points were noted before identifying the processor with many innovative features). Also, at
software process and framework: Microsoft, significant emphasis was on programming,
Microsoft work culture: The work culture at Microsoft at rather than on system architecture documentation. In XP,
that time was informal - software engineering staff programming forms the core, and it allows programmers
handled project execution decisions; roles were to take decisions about the design. This would have
worked well with engineers like Hunt – one of the

www.ijaers.com Page | 143

International Journal of Advanced Engineering Research and Science (IJAERS) [Vol -5, Issue-7, July- 2018]
https://dx.doi.org/10.22161/ijaers.5.7.21 ISSN: 2349-6495(P) | 2456-1908(O)
programmers responsible for deciding on the features for bags are not misplaced
Word. Airport Staff The system must not break since
Informal work culture: Traditional methodologies are there is no backup in place
rigid and do not work well in informal settings [13], but
XP can work very well in such configurations. For The needs of the stakeholder’s lead to the project’s
example, pair programming, one of the tenets of XP, can requirements. Based on the date the airport is scheduled
be beneficial when developers are comfortable working to open, the project must be completed within 22 months.
closely with each other. Small team sizes at Microsoft It has to be entirely accurate for bags to be delivered to
could support such practices. Furthermore, it is unrealistic the right place. It cannot have any downtime. It also has
for them to use a cumbersome process such as RUP to move the bags physically faster than any other system
which requires a highly structured and complex team with before, which allows planes to have a faster turnaround
many roles and requires tool support. time. However, the system is far too complex to design
Focus on quality: Bill Gates wanted this to be the “best and implement within the desired time window. As
word processor ever” and much time was to be spent on Neufville pointed out [8], planning the people mover in
getting every feature right. Characteristics of XP such as the Atlanta airport was the subject of two years of
refactoring (restructuring the program to improve quality ) research and a doctorate dissertation, and that system was
and continuous testing (continuously writing unit tests, comparatively simple. As the development cannot
which must run for the development to continue) would realistically be completed within the scheduled
serve this purpose greatly. timeframe, it is assumed the DBS is delivered in
Having a working system at all times: Some Microsoft increments to have a working system eventually.
managers were of the opinion that a “shippable” product By studying the system requirements, of the Denver
should be available at all times – after a piece of Baggage System, it seems the creation of the Denver
development is complete, all error and boundary cases Baggage System would be best handled with a traditional
should work, and it should successfully integrate with the Rational Unified Process (RUP) framework [11]. RUP is
rest of the system. XP facilitates just that with continuous appropriate for a variety of reasons:
integration. It says that the system should be built many RUP puts a strong emphasis on the design of a system,
times a day, every time a task is completed. this is required as the complexity of the system requires
User collaboration: Since the market focused on multiple thorough planning.
large business corporations and government agencies, the RUP promotes component-based architecture which
way to elicit requirements should be through user enables modeling of real-world systems and integrates
collaboration. An iterative process is required to elicit well with the development of those systems [2]. This is
user requirements and feedback. An agile process like XP very important for the DBS project since the physical
best does this. design of the DBS is constrained by the architectural
Extrapolating the engineering culture and project design of the airport and the physical realities of the
management structure at Microsoft an iterative and conveyor system.
incremental lifecycle with a light, agile process like XP RUP process is designed for delivery in increments. As
would be a good candidate for the MS Word project by explained before, it is not possible to deliver the entire
providing structure for new requirements, delivery under system in working condition by the deadline. Delivering
time constraints, and code-intensive development. some sub-portion of the system s hould be possible.
RUP’s incremental delivery design allows the system to
III. CASE STUDY: DENVER BAGGAGE SYSTEM expand as it is developed.
Before determining what process and framework would Delivering the system in increments forces the creation of
be useful for the Denver Baggage System (DBS) [10], a manual backup system. Some bags would have to be
notes are taken on the nature of the project. There are manually transported to the terminal until the entire
several stakeholders on the DBS project, and each has system is online. This helps maintain system reliability
their expectation for the system (see the table below). because if the system fails, there is a process and
Stakeholder Need procedure for replacing the lost functionality.
Airport The project must be completed on Due to many investors in the DBS project, project
time as delays cost money accountability is a requirement. The extensive
Airlines Planes must be loaded as quickly documentation and artifacts produced by RUP provide the
as possible accountability mentioned above.
Passengers The system must be accurate, so When comparing RUP to other process frameworks, it is
apparent why, in this cas e, it is the superior process. RUP

www.ijaers.com Page | 144

International Journal of Advanced Engineering Research and Science (IJAERS) [Vol -5, Issue-7, July- 2018]
https://dx.doi.org/10.22161/ijaers.5.7.21 ISSN: 2349-6495(P) | 2456-1908(O)
has advantages over more agile frameworks like XP in DOT covers many more functions than just vehicle
that this project is very design heavy. Much planning is registration). Thus, PennDOT21 should be modular and
needed to ensure that all the parts of the system integrate modifiable.
together successfully. Quality: One of the main concerns for the PennDOT21 is
RUP is better than waterfall-style processes since the security, as transmitted data might include sensitive
DBS project needs incremental deliveries not present in information such as registration numbers. Furthermore,
those frameworks. the system must provide 24x7 access and thus must be
The DBS project does not need the risk management of a error-free and robust. Concurrency and scalability is an
spiral process since the risk is managed by the forced issue, since there may be a large number of users
development of a backup system. accessing the system at one time.
From the above factors, the most critical project
IV. CASE STUDY: PENNDOT21 requirements are summarized as follows:
The goal of the PennDOT21 project is to provide on -line  Robust, secure, scalable, modular and modifiable
vehicle registration services by making a web interface back-end communication with PennDOT.
for the PennDOT registration system [12]. This system  Intuitive and flexible, but secure front-end web
should be a secure and easily accessible service to all interface.
licensed Pennsylvania drivers. The critical factors in  Clear indicators of project progress.
determining a lifecycle for this project are as follows:  Extensive testing to ensure code integrity.
Stakeholders: The significant stakeholders include the The points above show a dichotomy in the requirements
Pennsylvania Department of Transportation, its for this project. On the one hand, the robust back-end
employees who work with the system, and all licensed suggests a traditional process with particular attention to
Pennsylvania drivers. Because the technical competence design and architecture. On the other hand, the easy -to-
of the end users varies, the web interface must provide a use front-end suggests an iterative, agile process with
highly accessible and intuitive GUI. It suggests an extensive feedback to make the interface as intuitive as
iterative lifecycle with feedback to determine GUI possible. Therefore, the best fit process is a merge of both
requirements. agile and traditional processes.
Market: We assume that the PennDOT21 system is ACDM [7] with Rapid Prototyping [9] provides the best
mostly the first of its kind and therefore may serve as an fit for this project. ACDM's architecture-centric approach
example system for other states in the future, this suggests gives the best chance of success in fulfilling the need for a
a process with clear indicators of progress. robust, secure, and scalable system. Furthermore, ACDM
Technology: PennDOT21 to provide an interface with the provides a clear way to track progress by use of the
older PennDOT vehicle registration system. Thus, there architecture [3], even though rapid prototyping itself may
must be proper testing to ensure that this integration is not produce clear progress indicators. Rapid prototyping
secure and robust. is used in the production phase because its attitude
Business Drivers: The business goal of this project is to towards changing requirements and extensive feedback
reduce errors and work required in the existing manual allows it to provide an intuitive and easy-to-use interface.
registration process. Because a manual process already ACDM guides the development, so there is no loss in
exists, this suggests a backup exists for PennDOT21 in security or robustness. Furthermore, rapid prototyping's
case of failure and also that continuous deployment is code-centric attitude ensures a minimum of bugs, and this
possible. is especially true for PennDOT21 which would be a small
Culture: End-users and employees are unaccustomed to or medium software size [2].
using the web interface. Thus, a gradual deployment with ACDM with Rapid Prototyping [9] is the best possible
training is required for a successful project. process for this project. Security, scalability, robustness,
Time/schedule: A time constraint is not a primary and modifiability are all attributes that are addressed
requirement of this project because there is already a while examining the architecture of a project.
manual process by which drivers can register their Furthermore, PennDOT21 is not a life-critical system,
vehicles. Since the interface is dependent on the manual and has a backup manual registration service (as
process, any changes in the manual process might affect assumed), so heavyweight processes like Spiral or RUP
the schedule. are not essential to its development. Next, ACDM should
Scope: The scope listed in the project description only be combined with an agile process for development since
covers an interface for vehicle registration. However, it is the exact requirements for an intuitive web interface
feasible that the scope might be extended in future cannot be well-defined early in the project. In this case,
projects by the DOT if the project is successful (since the Rapid prototyping is the best agile process to combine

www.ijaers.com Page | 145

International Journal of Advanced Engineering Research and Science (IJAERS) [Vol -5, Issue-7, July- 2018]
https://dx.doi.org/10.22161/ijaers.5.7.21 ISSN: 2349-6495(P) | 2456-1908(O)
with ACDM because of Rapid prototyping's code-centric  Private and military avionics industry
approach and attitude towards changing requirements.
Another approach like scrum might focus on the Technology:
management side, which may not be necessary for this  Real-time, Embedded
project (depending on the specifics of the development  Communication between each device has to be
team). near real-time

V. CASE STUDY: FLIGHT CONTROL SYSTEM Business drivers:

The aircraft flight control system (FCS) is a high-risk  Early generations of FCS were mechanically
flight system that controls every aspect of an airplane based, so pilots had to physically steer and
operation to ensure safer, smoother flight; it consists of control the aircraft, which was limited by the
the flight control surfaces, cockpit controls, and the physical capabilities of the pilot [4].
necessary mechanism to control the aircraft’s direction in  Development of digital FCS would automate the
flight. process.
FCS requires:  Increase in safety as the pilot can concentrate on
 Good aircraft handling properties high-level tasks rather than routine control tasks.
 Low pilot workload Culture(s):
 Model simulation or prototyping is required to The spiral model [5] along with Six Sigma strategy is a
analyze whether digital processing signals represent good fit for the project. The project would consist of
the desired implementation, to avoid any mishap interactions between software engineers, embedded
during the ground or flight testing[4]. systems developers, six sigma black belt members (to aid
 Backup or failover plan in case of software or high quality and defect free deliverables), testers, change
hardware fault. management group (risk, impact analysis and versioning),
 The system developed should be comprehensively analysts and pilots (for live testing of the system).
tested for an extensive set of faults and have Time/schedule, resources, scope, and quality:
thorough ground-based testing. The system and its This project, being safety critical, requires thorough
inherent functional design should be free from testing, simulation, high-quality standards, zero defects,
errors. and adequate documentation. The spiral model
incorporates the above requirements with a fast-iterative
Additionally, FCS requires adherence to the highest level approach, and a team of six sigma competent members
of quality standards. Any failure in the system can cause would work on quality, risk management, cost, and
loss of aircraft and human lives; the probability of success estimation in sync with spiral model phases. Hence, the
should be very close to 100%. However, a test to prove spiral model fits the project well.
100 percent correctness is almost impossible. Thus, a Six Sigma:
trade-off is done by deploying many reliable, redundant Due to the lack of emphasis on documentation with the
artifacts, a thorough design and development process, and spiral model, its weakness is strengthened by combining
test-cases under all possible combinations of inputs. it with Six Sigma strategy. Six Sigma [6] improves the
Redundant artifacts would be used as backup during any quality of process outputs by identifying and removing
software fault. the causes of defects and minimizing variability in
The project is high risk, safety-critical, and requires zero manufacturing [7]. In a Six Sigma process, 99.99966% of
defect deliverables along with continuous risk the product is expected to be bug-free. The five phases of
assessment. Thus, a spiral model is proposed as the six sigma process are defined, measure (identifying
software development process along with six sigma critical to quality and risks), analyze (high-level design),
business management strategy. This gives a combination design (simulate and optimize) and verify (set up pilot
of prototyping, continuous refinement and near-zero runs). This along with the spiral model would provide a
defects. thoroughly tested, well documented, bug-free, high-
Here are all of the factors taken into consideration: quality deliverable.
Stakeholders: Considering that the key for developing aircraft flight
 Pilots, Passenger control is safety, we have concluded that the Spiral
 FAA (Federal Aviation Administration) process is the excellent fit for this project. Spiral model
 Airlines encapsulates iterative development with prototyping,
 Market: verification and validation, and a waterfall approach in

www.ijaers.com Page | 146

International Journal of Advanced Engineering Research and Science (IJAERS) [Vol -5, Issue-7, July- 2018]
https://dx.doi.org/10.22161/ijaers.5.7.21 ISSN: 2349-6495(P) | 2456-1908(O)
incremental order. Finally, six sigma provides the system. Harvard Business School Teaching Case, (9-
documentation that the spiral model lacks, as well as 396), 311.
ensure further quality control to the highest level. [11] Kruchten, P. (2004). The rational unified process: an
introduction. Addison-Wesley Professional.
VI. CONCLUSION [12] Poister, T. H., & Larson, T. D. (1988). The
We have seen in the above four cases that different Revitalization of PennDOT. Public Productivity
circumstances can call for very different development Review, 85-103.
models. High-risk applications such as the Flight Control [13] Devadiga, N. M. (2017, November). Software
System require traditional models with features such as Engineering Education: Converging with the Startup
risk assessment and thorough testing or simulation. On Industry. In Software Engineering Education and
the other hand, products in a highly competitive market, Training (CSEE&T), 2017 IEEE 30th Conference
such as MS Word, might require a more agile process for on (pp. 192-196). IEEE.
faster time to market. Many factors such as stakeholders, [14] Ambler, S. (2002). Agile modeling: effective
business culture, technology, and risk must be considered practices for extreme programming and the unified
for selecting the most appropriate model, and a full process. John Wiley & Sons.
analysis of any project should be carried out before
selecting a process.

REFERENCES
[1] Gill, G., &Iansiti, M. (1994). Microsoft corporation:
Office business unit. Harvard Business School Case
Study, 691-033.
[2] Tsui, F., Karam, O., & Bernal, B. (2016). Essentials
of software engineering. Jones & Bartlett Learning.
[3] Lattanze, A. J. (2005). The architecture centric
development method. Carnegie Mellon University,
School of Computer Science [Institute for Software
Research International].
[4] Pratt, Roger W. "Flight Control Systems: Practical
Issues in Design and Implementation, 2000." The
Institution of Electrical Engineers.
[5] Boehm, Barry. "A spiral model of software
development and enhancement." ACM SIGSOFT
Software engineering notes11.4 (1986): 14-24.
[6] De Feo, Joseph A.; Barnard, William (2005). JURAN
Institute's Six Sigma Breakthrough and Beyond -
Quality Performance Breakthrough Methods. Tata
McGraw-Hill Publishing Company Limited.
[7] Antony, J. (2004). Some pros and cons of six sigma:
an academic perspective. The TQM magazine, 16(4),
303-306.
[8] De Neufville, R. (1994). The baggage system at
Denver: prospects and lessons. Journal of Air
Transport Management, 1(4), 229-236.
[9] Devadiga, N. M. (2017, October). Tailoring
architecture centric design method with rapid
prototyping. In Communication and Electronics
Systems (ICCES), 2017 2nd International Conference
on (pp. 924-930). IEEE.
[10] Montealegre, R., Nelson, H. J., Knoop, C. I., &
Applegate, L. M. (1996). BAE automated systems
(A): Denver International Airport baggage-handling

www.ijaers.com Page | 147