The Concept Selection of Lean Software and System Engineering Tools for Smart Cities, AM Redmond¹, A Zarli

Tags: development, Scrum, architecture, requirements, software development, EVA, HVAC controllers, mechanical systems, bus topology, point system, Agile methodologies, points system, electrical systems, foundations, Agile methods, systems of systems approach, JACE Controllers, java virtual machine, distributed system, networking structure, traditional methods, C. Architecture, technical practice, development process, security systems, development foundations, product owner, scale algorithms, system layers, energy-efficient solutions, evolution development, Mobile Edge Computing, Smart Cities, IoT, MEC, autonomous control, Winston W. Royce, SPI, Vanderbilt University, Scrum Master, customer demand, Agile Development, Elizabeth Long Lingo, team members, Agile method, ETSI Industry Specification Group, Kanban system, supply chain
Content: The Concept Selection of Lean Software and System Engineering Tools for Smart Cities
Dr Alan Martin Redmond№, Numйrique Consulting Dublin, Ireland [email protected]
Dr Alain ZarliІ Centre Scientifique et Technique du Bвtiment Sophia Antipolis, France [email protected]І
Abstract-- An integrated understanding of the Smart City hypothesis, is that these projects are a part of a general concept of city modernisation. However, smart city projects should never be seen in isolation, but as one element in a city's (or a region's) continuous effort to find the next best way of operations. This paper evaluates the problems associated with the systems development of Agile technical practices for developing IoT solutions for Sustainable Urban environments. As part of this analysis; this paper investigates the traditional methods of generic lifecycle stages; iteration and recursion, sequential methods, and incremental and iterative methods for developing urban informatics. The functional design of a distributed automated system architecture is presented based on the theory that team members such as software engineers, data specialists, security engineers, testers, and other specialists need to be self-organized and embrace the certainty of failure. The authors' identify that by using Agile techniques to decrease fear of failure and embrace the notion that the goal should be to experiment constantly, fail early and often, and learn as much as possible in the process can produce a more integrated service. The end result is a hybrid model presented as part of a process analysis practice for IV&V in order to develop value added solutions for Smart Cities. Keywords--Agile Development; Scrum & Kanban; Smart City Requirements; Systems Engineering; IoT I. INTRODUCTION The generic life cycle stages as identified by (1) lists; concept, development, production, utilization, support and retirement. They recognize that the purpose of the concept stage is to define the problem space. Within this domain "many industries employ an exploratory research activity to study new ideas or enable technologies and capabilities, which then can mature into initiation of a new project". The generic life cycle (ISO/IEC/IEEE 15288:2015) is somewhat different from other life cycle models that start the process with "requirements" or "user requirements". The generic life cycle process focuses on the preliminary concept being investigated and what is necessary to identify technological risks and to access the Technology Readiness Level (TRL). Additional key activities associated with this stage is early cost and schedule projections and technical feasibility. The second activity of the concept stage is referred to as `Concept Selection'. The concept selection operation features activities such as the operational concept (OpsCon ­ describes how the system works from the operator's perspective i.e. summarizing the needs, goals and
characteristics). Also during this stage evaluations, mock-ups, simulations and prototypes are built and tested in order to identify the stakeholder's needs. The requirements of the concept stage involves defining Integration, Verification, and Validation (IV&V). The structure of this paper follows a similar process to that of the concept selection description. The principles of selecting lean software tools and system emerging tools for SMART Cities is connected to the Scaled Agile Framework® (SAFe®). "SAFe was developed in the field, based on helping customers solve their most challenging scaling problems. It leverages three primary bodies of knowledge: Agile development, Lean product development, and Systems Thinking (scaledagileframework.com) and (2). This paper will discuss the comparison of software agile development methodologies i.e. Kanban vs Scrum, techniques for tracking such as investigating if the traditional Earned Value Analysis (EVA) is far superior than the Agile method of story-point based tracking. Also the difference between testing Smart City software products using Vee model and Agile. A process analysis of implementing an Agile Framework will be used to propose a distributed automated system architecture for verification and validation for Smart Cities. The next section evaluates the role and skill-set of thinking patterns. II. ROLE AND SKILL-SETTING PATTERNS A. Defining and Investigating Roles and Skill-Set The declaration of the Agile Manifesto in 2001 spawned interest in a number of methodologies such as Scrum and Extreme Programming. In 1991 as cited by Nigel (1992), "technology and the environment in which it is deployed are coevolving at an increasing rate, outpacing the adaption capabilities of most organized human endeavors" (1). In the authors' opinion, the adoption of such methodologies need significant consideration as different scenarios require separate techniques. In order, to clarify the basics of Agile development the authors will explain what is role and skill-set thinking and why they are detrimental to a SCRUM implementation. By defining and investigating roles and skill-sets this section will explain the advantages of SCRUM to software development teams. Table 1 outlines the main five specific roles for implementing Agile development as suggested by Department of Defense (DoD).
TABLE I.
FIVE SPECIFIC ROLES FOR IMPLEMENTING AGILE
Roles Product Owner Scrum Master Integrated Team
The DoD - IT program has five specific roles for Implementing Agile (3) Seen as critical with responsibilities including; · Understanding and communicating the user's and stakeholders' concepts of operations to the engineering team i.e. product vision and value proposition; · Managing the product backlog and refining its contents on a daily basis; · Ensures that the backlogs with the most important operational concepts are being addressed by both defined and derived requirements; · Collaborate with the team on a daily basis to answer questions and sign off results. Facilitates the scrum process, protects the team from interference and removes barriers so that the team can deliver the sprint goal. Most important duties include; · Act as a buffer between the team and any distracting influences; · Ensure that the Scrum process is used as intended; · Be the enforcer of team rules; · Remove obstacles and protect the team to keep them focused on the task at hand. Responsible for developing and integrating the software required to meet program capability requirements. The team includes; software engineers, data specialists, security engineers, testers, and other specialists as needed. The team is self-organizing.
Stakeholders
Is applied to anyone who has a vested stake in the project. This includes those people who enable the project or who receive an agreed upon benefit.'
Users
Refers to anyone who will be a direct (anyone who uses a program service or component) or indirect user of the program system (use a service or component, not directly, but through another piece of software).'
B. Defining Scrum "The term `Scrum' comes from the game of rugby, and it refers to the way a team works together to move the ball down the field. Careful alignment, unity of purpose, and clarity of goal come together. It embraces uncertainty and creativity, it places a structure around the learning process, enabling teams to assess what they've created and, just as important, how they created it. The Scrum framework harnesses how teams actually work and gives them the tools to self-organize and rapidly improve both speed and quality of work (4). The Scaled Agile Framework states that the ScrumXP Agile team is a selforganizing, self-managing, and cross functional group of five to nine people, located wherever possible. The teams intent is based on iterations and is solely responsible for determining how much of that scope they can actually commit to, and how they will increment value. A key aspect of Scrum is the crossfunctional aspect where all the roles and skills are needed to deliver an increment. Another key component is the ability to execute a full Plan, Do, Check, Adjust (PDCA) as quickly as possible because it helps the Scrum to plan together, integrate, demo and learn together. This leads to the `inspect and adapt cycle' at the end of each program increment.
Fig. 1. PDCA in Iterations (Sourced from: Scaled Agiled Framework http://www.scaledagileframework.com) C. Defining Skill-Set (4) cited how Professor Takeuchi and Nonaka in their original paper titled "The New New Product Development Game" described the characteristics of the teams that they perceived as the best companies in the world: 1. Transcendent ­ this self-realized goal allows a sense of purpose to move beyond the ordinary into the extraordinary, 2. Autonomous ­ the teams are self-organizing and selfmanaging and they have the power to make their own decisions about how they do their jobs, 3. Cross-functional ­ the teams have the skills needed to complete the job i.e. planning, design, production, sales and distribution. "When all the team members are located in one large room, someone's information becomes yours, without even trying." The team is the key force behind the scrums and Professor Takeuchi and Nonaka's three characteristics of excellent teams highlighted the need for self-organization and management. They also noted that teams have skills such as planning which are required for completing the job. In order for a partnership to exist the partner's need to work together and perform. They emphasize on different team members having different skills sets and exposure should not be an issue as "everyone on the team should bring something to the table" if a member is not bringing value in achieving objectives, the partnership becomes dysfunctional. D. Investigating Roles and Skill-Set According to (5) teams and organizations have resisted Scrum for many reasons but a likely opposition to adoption was the confusion over the new roles. The two roles in particular were ScrumMaster and Product Owner. In order to define a ScrumMaster role (5) outlines the characteristics of a good ScrumMaster;
1. Responsible ­ maximizing the throughput of team while assisting team members in adopting and using Scrum, "ScrumMaster thrives on responsibility that special type of responsibility that comes without power." 2. Humble ­ a ScrumMaster is willing to do what is necessary to help the team achieve its goal. They recognize the value in all team members and lead others to the same conclusions. 3. Collaborative ­ they create a collaborative atmosphere for the team through words and actions, they also encourage teams to think in terms of solutions that benefit everyone rather than in terms of Winners and losers. 4. Committed ­ does not end many days without impediments being unaddressed. 5. Influential ­ influence team members i.e. convince a team to try a new technical practice such as pair programming or test-driven development, exert influence without resorting to dictatorship. 6. Knowledgeable ­ they do not need to be programmers but they should have enough experience to lead programmers. In the context of self-organizing, (5) highlights that the benefit of such a practice isn't that the team finds some optimal organisation that a manager may have missed but rather, by allowing the team to self-organize, encourages the team to fully own the problem. (6) presented Elizabeth Long Lingo of Vanderbilt University joint research project with Professor Siobhan O'Mahony of the University of California, Davis on the production of country music in Nashville. Long Lingo emphasized that the music business requires integration of many parties ("quite similar to a Scrum") including songwriters, publishers, artists, and label personnel. She also noted that the person bringing it all together is the producer ("quite similar to a product owner"). The role of the producer is based on leadership that has no clear yardstick for how good the product is and no clear rules on who gets to control it, however an effective producer creates a shared purpose and lets others apply their distinctive expertise. `For example; producers may introduce "bad song" and "good song" samples to create a common aesthetic but still allow the space for experts to experiment with their own sound and forge their contribution to the project'. In the authors opinion, this is self-organizing and this practice draws upon the quality of embracing the certainty of failure. (6) suggest that managers must decrease fear of failure and that the goal should be to experiment constantly, fail early and often, and learn as much as possible in the process. Again, the reason why role thinking and skill set thinking are detrimental to Scrum is because they embrace responsibility avoidance, individual contribution and win/lose mentality. "Role thinking essential refers to only being concerned and responsive to your role and likewise skill-set thinking refers to only engaging with tasks that relate to your specific skill-set." E. Implementing Agile Development A key lean manufacturing principle of the Kanban system is the minimum level of inventory created by producing only what is required. "It ensures the supply of the right product, at the
right time, in the right quantity and at the right price." It synchronizes all manufacturing activities with customer demand (7). The operational success of production scheduling is "based on demand" for which, pushing refers to the ability to the demand-forecast (demand by corporate supply chain and business management). However, with Kanban the "pull" comes from the demand and the production is determined by the actual demand of the customer. In order, to alleviate the complications associated with lengthy supply times and difficult to forecast demands, the Kanban system uses a demand signal. This signal manages the intermediate stock held in the supply chain at a smaller size. With regards, to difficulties meeting supply response to actual demand fluctuation and loss of sales, the solution requires simply adding more Kanban into the system. Kanban cards are an essential part of the signaling system because it identifies when to move materials within a production facility and to move them from an outside supplier into the production facility. In effect, the card is a message that highlights depletion of products parts or inventory (8). The electronic Kanban system sometimes referred to as the EKanban Systems eliminates the problems such as manual entry errors or lost cards. The benefits of the E-Kanban systems relate to integration with Enterprise Resources Planning (ERP) systems which enables "real-time demand signaling across the supply chain and improved visibility (9). The structure of the Kanban Boards illustrates the current status of all the tasks to be done within an iteration. The board is separated and labeled into three titles; ToDo, Doing, and Done. The tasks that are associated with each section are written on cards and posted to the board. Other types of Kanban visualisation boards is; i) "Feature Kanban Board" ­ which is made-up of horizontal axis that represent the timeline and vertical areas within the timeline that indicate releases. The cards posted to each area represent a feature that will be used in the release, ii) "Parking Lot Chart" ­ which is used to provide a top-level simplified summary of the projects status for example; read only Merge 100%, progress bar (read ­ 50%), progress bar (write ­ 0%) and merge utility (0%), iii) "Calendars" ­ such as Niko-niko calendars that show project status to plan, and iv) "Burndown Chart" ­ the key component of a burndown chart is to count the numbers of Kanbans (backlog tasks) and track them in a time box in order to present the pattern of work accomplished (10). Table 2 is adapted from (11) where he suggests that Scrum is more appropriate for "an organization that is in a need of a fundamental shift towards a more efficient process." Whereas, improving a process over time without impeding the whole system, "Kanban should be the tool of choice." The SAFEe 4.0 for Lean Software and Systems Engineering recognizes both Scrum and Kanban as part of the Team Level abstract because each "routinely delivers high-quality systems and produce a System Demo every two weeks which ensures that all different teams on the Agile Release Train (ART) will create an integrated and test system that stakeholders can evaluate and respond to with fast feedback." This section outlined the various components associated with choosing Agile development methodology as a lean software and system engineering tool. The following section will address the
SMART City requirements for developing an embedded system design for energy efficiency in neighborhoods and cities.
TABLE II. Attributes
COMPARING THE SUITABILITY OF KANBAN VS SCRUM TECHNIQUES Comparing the Suitability of Kanban vs Scrum Techniques for Agile Development Methodology - adapted from, (11)
Framework
Scrum is a well-defined process framework for structuring work.
Kanban is less structured than Scrum as it has no process framework.
Introducing the technique Methodology Change Agent
Introducing Scrum is quite a challenge for a team not used to Agile software development i.e. iterations, build cross-functional teams, appoint a product owner and Scrum Master, sprints reviews etc. Scrum has less excessive specifications and fewer handovers due to crossfunctional teams and more flexibility in roadmaps and planning due to short sprints. Scrum leverages team commitments as a change agent. The type of changes consist of taking more responsibility, raising code quality, and increasing speed. As teams commit to sprint goals, they are intrinsically motivated to get better and faster in order to deliver what is promised.
Kanban principles can be applied to any process that is already running even to Scrum. The Kanban board is used for organizing work. The only management criteria introduced by Kanban is `Work In Progress' which optimizes flow of work items. Besides visualizing work on a Kanban Board and monitoring WIP, nothing else needs to be changed to get started with Kanban. WIP limit should be defined on every column on a Kanban board. It identifies how much work items are allowed to be in a certain state at any given point in time. If a state reaches a predefined limit no new work can enter. These work items become visible clusters on the Kanban board. Such visible bottlenecks identify where the process needs to be improved. The change agent avoids future bottlenecks.
III. METHODOLOGY A. SMART City Requirements (12) acknowledges that in "the right context and at the appropriate scale algorithms are useful for Smart Cities but the complete surrender of municipal management to an algorithmic toolset (as implied by the word autonomous) would seem to repose an undue amount of trust in the party responsible for authoring the algorithm." (13), identified that ambient intelligence (electronic environments that are sensitive and responsive to the presence of people) and autonomous control were not a part of the original concept of Internet of Things (IoT). In fact, they do not require internet structures but (13) recognizes that "there is a shift in research to integrate the concepts of the IoT and autonomous control." (14) showcased
The `Execution Models for Energy-Efficient Computing Systems' (EXCESS) project that investigated the lack of holistic integrated approaches to cover all system layers, from hardware to user level software. The project acknowledged that a framework needed to be developed that would allow for rapid development of energy efficient software production. The EXCESS framework provides 54 times more energy-efficient solutions compared to a standard implementation on a high end PC processor and it continues to show benefits using an embedded processor (15) acknowledges that there are many different IoT architectures deployed around the world depending on economics, OPEX, CAPEX, and available communications. They also recognize that these devices operate multiple heterogeneous edge links between end sensors and/ or actuators and the head-end IoT system. However, they insist that Next Generation Protocol (NGP) evolution is key to IoT communication architecture. ETSI foresee that the NEXT Generation architecture avant-garde is to deploy full or partial IoT application and /or partial database using Mobile Edge Computing (MEC ­ a new technology which is currently being standardized in the ETSI Industry Specification Group -ISG). "It provides an IT service environment and cloud-computing capabilities at the edge of the mobile network, in close proximity to mobile subscribers, in order to reduce latency and provide a highly efficient network operation. (16) acknowledge that the telecommunications and IT industries have implemented several technological advancements that will assist the deployment of MEC solutions such as the progress of cloud computing and virtualization that will allow applications to be deployed on top of the MEC platform. They forecast that the economy of scale of MEC will be based on readily available hardware platforms featuring highly standardized IT components. B. Tracking Techniques EVA is a control tool which uses the project estimates and associated allowances. The project programme is a source of reference and the allocation of cost data is paramount to getting a true picture of the project at any given moment. The three data values associated with EVA are; Budgeted Cost of Work Performed (BCWP), Budgeted Cost of Work Scheduled (BCWS) and Actual Cost of Work Performed (ACWP). When calculating performances i.e. cost performance index (CPI) and scheduled performance index (SPI) the following equations are used; CPI = BCWP/ACWP and SPI = BCWP/BCWS. "For both values, anything greater than one signals that the project is being completed less than the budget and is ahead of schedule (17). Table 3 compares the traditional tracking method of EVA to that of Agile method of story-points based on five metrics; measuring, planning, units, forecast and risk. In the authors' opinion, there is both pros and cons for each of the five performance metrics associated with traditional EVA and Agile Methods and for this reason the proposed solution is to use a hybrid technique involving both. (18) identifies and compares some of the changes facing systems and software such as `traditional development' being accustomed to; standalone systems, relatively stable requirements, requirements determine capabilities, control over evolution of
custom systems and enough time to keep stable in comparison to `current/future trends'; everything connected, rapid requirements change, commercial off-the-shelf (COTS) capabilities determine requirements, no control over evolution of COTS products, and ever-decreasing cycle times. TABLE III. COMPARING EVA TO AGILE METHOD
Iterative Development (IID) Methods from sequential approaches are "velocity and adaptability." INCOSE acknowledges that "while market strategies often emphasize that time to market or speed is critical, a more appropriate criterion is velocity, which considers direction in addition to speed. INCOSE shows the evolution development cycle of IID (derived from 19) from the Preliminary Design Review (PDR) increments to the Test Readiness Review (TRR) version for system acceptance and delivery.
Comparing EVA to Agile Method of Story-Point Based Tracking
Attributes
Traditional
Agile Tracking
Measuring Planning Units Forecast Risk
In contrast to Agile tracking EVA seems rigid and the forecasts are set to a specific programme that is not flexible to changes and probably suitable to software development methods such as Winston W. Royce original 1973 waterfall model. In a traditional model WBS is key to planning and reflects BCWS as upfront necessities in order to start the process, whereas Agile starts with FBS and then during release planning iteration planning is broken down into more details. Cost ­ is a key measuring unit for traditional i.e. measure actual money spent. The analysis such as BCWS, BCWP and ACWP define if you are behind schedule, what percentage you are running at, and percentage you are over budget. Against the WBS and program these are useful techniques however, for changes and indecisive items that require iterations and testing a more flexible approach is required. There may be problems with defining schedule variance (SPI), if the project runs longer than originally scheduled and this is because unlike Agile the traditional results are based on budgeting and not schedule estimates. The main focus of risk is how to reduce or transfer risks with a model that is sequentially planned to adhere to sequence of events .i.e. testing, prototypes may present results that require the release of a product to be changed completely altering the marketing events due to features underperforming or requiring additional attention. With EVA tends to have end of program testable features which require additional time.
A story point is an arbitrary measure used by SCRUM teams to identify the effort required to implement a story. In simple terms it tells the team how hard the story is i.e. complexity, unknowns. The stories must be actionable and finished on its own, they can be rewritten, small and testable (4). Feature Breakdown Structure are advantageous because; - They allow communication between the customer and the development team in terms both can understand; - They allow the customer to prioritize the team's work based on business value; They allow tracking of work against the actual business value produced. Estimation units - programmers can identify the relative work required to get different features done, this is why Agile enables comparison between each technical tasks and the nonprogramming becomes clear as the velocity emerges after a few iterations. Work units ­ points, gummi bears, foot-pounds and nebulous of time (NUTs) represent the relative amount of work required to implement a feature (or task), compared to other features. Both ideal-time and work units exclude non-programming time, they only specifically refer to the programmer time required to get a feature done. However, only after a few iterations will a real velocity emerge. The accumulating of points is shown in the iterations chart ­ and these charts are used to measure the velocity of Agile teams and its progress. The stabilizing of velocity through the life of a project and the acceptance of priorities, goals and teams changing over time can be used to plan future releases. Agile methodology ­ allows for minimizing the overall risk by addressing early in the project the high risk features such as design architectures, framework or algorithms that are new to the team. However, it is essential that meetings are planned to prioritize with the client features that are critical to the process.
He illustrates the traditional systems engineering V-model and explains that `the model has evolved over-time but the fundamentals still provide a basis for a life cycle used by the defense system acquirers' i.e. "establish requirements, an architecture, decompose the system into sub systems and test the system." He also, acknowledges the so called Promised Land portrayed by advocates of Agile development for example; victory over rapid change, increased complexity, emerging requirements and ubiquitous scheduling integration. The problem he notes with Agile refers to the risks reduction activities of the iterative process rather than sequential. (1) emphasize that the features that distinguish Incremental and
It also, presents (20) spiral model which under a 6 point system (featuring; exploration, valuation, foundations, development foundations, operation development foundations and operation development foundations) extensively reviews risks for each phase of the release cycle. In summary, the authors of this paper anticipate that because of the risk driven process of today's product market, the objective should be to incorporate cycles that allow for both Agile and traditional methods i.e. where a release allows for sequential operations EVA can be incorporated but for speed and agility the process should be partially aligned with Agile methods. (3) suggests
when using both methodologies it would be wise to separate them in order to minimize confusion but to also synchronize the activities of both such as; cross-project coordination i.e. encouraging both teams to attend each other's project meetings. C. Architecture The authors' propose an architecture that is based on a systems of systems where the overall framework would encompass various devices from manufactures accompanied with protocols also associated with their respected companies. In order, to synchronize data input into outputs so the electrical systems of controllers connected to sensors would be connected to the mechanical systems (HVAC controllers). Fig. 2. Java-based based Framework for IoT Solution
environment. The systems of systems approach is that the framework is Tridium's Niagara (21) and the products JACE controllers are Vykon however, the protocols for some of the devices are BACnet and the java virtual machine programming runs on various windows. Within the structure there is a hybrid approach to the Network Design (hardware) being WiFi or twisted pair cables operated or even both. Figure 2 shows the `Java Based Framework' using a Hybrid networking structure possibly bus topology for passing the traffic to each PC (messaging, commands etc.) and star topology (22) for twisted pair cabling using LonTalk protocol for communication of data. As Figure 2 indicates the overall simple concept is to design a web user interface that will control the electrical, mechanical and security systems of a buildings automated system (small commercial size building ­ depending on the size of the chosen JACE controllers). · The architecture shown in Figure 3 denotes the infrastructure of a multi-operator, multi-access and FMC scenario connected to IoT gateway (Control Domain) which provides the connectivity between the bus topology (field bus domain) and the sensors (Distributed Automated domain); · Operator A: 3GPP network system specifies network control polices to manage both fixed broadband and mobile access (LTE/5G) either simultaneously or individually;
Fig. 3. Distributed Automated System using a Multi-Operator, Multi-Access and Fixed Mobile Convergence (FMC ­ adapted from (15) and (21) Legend: IoT ­ Internet of Things, DMZ - demilitarized zone, 3GPP ­ Third Generation Partnership Project) The main access to the system is based on a web browser activated by an interface supervised by a desktop software
· Operator B: relies on fixed broadband (FTTx/xDSL) technology for accessing public internet and private networks; · The concept is to manage and control both 5G radio access (mobile) and fixed access depending on the networks requirements (human or machine);
· The DMZ adds an additional layer of security to an organization's (an external network node can access only what is in the DMZ). For private cloud usage of services and devices the DMZ server will provide a secure access domain. Many of the JACE Controllers in the distributed system support cloud services directly without use of additional gateways. The "Internet Protocol does not currently accommodate a device to access multiple networks at the same time." Unfortunately at present this includes FMCs in the core network across multiple access technologies. However, "MEC is seen as a critical feature of Next Generation communications systems for low latency and service acceleration that cannot be achieved with current systems" (15). This means that future architectures are moving into this direction space. D. Java-based Framework ­ Scrum Roles In reference to Figure 2 and 3 architectures, the SCRUM master would define the story points associated with the architecture and create a points system and hours for the iteration process. It is the products owner decision to accept the stories gathering, maintaining and prioritizing data upon which the SCRUM master uses to update the iteration table. The SCRUM master also releases the burn down charts based on the stories (a story is a testable piece of a feature i.e. a chunk of functionality that delivers business value, which is described by users) and points accepted but it is the product owner who decides on which story has priority. Because it involves various teams such as full time staff (and possibly part-time) and management each segment (electrical and mechanical, hardware ­ network design and manufacturing, software interoperability, interface and communication) maintenance (back logs) and testing will be a priority. The developers and testers, technical writers will use the stories to build on the requirements (stakeholders etc.) and the product owner will evaluate the overall progress. However, before the iteration planning process a business analyst, product manager, a customer, or program manager would collect all the features for tracking against business value. With this type of system requiring a cross-functional segmentation the program manager would list and identify the type of expertise needed. IV. TESTING ANALYSIS The issue of making a "quantum leap" from requirements to a physical solution is referred to as a "point solution." (23) highlights that this physical solution may or may not be verifiable in meeting system requirements. These performance may be deficient in capabilities due to missing or conflicting requirements, or they may not satisfy the operational needs of the user for example; system validation in conducting their missions. His solution is to introduce a series of decisions in order to develop a design solution at each level of abstraction. The allocation of verification approaches is based on engineering methodologies, guidance and engineering procedures that lead to schedule & risk factors before creating specifications and interface control documents. (24) suggests that a verification section structure should be based on MILSTD-961E which identifies the following methods to accomplish verification; Analysis (A) ­ utilizing established
technical or mathematical models or simulations, algorithms, charts, graphics, circuit diagrams in combination with human analytical thought; Demonstration (D) ­ adjustment, or reconfiguration of items based on accomplishing specific scenarios; Examination (E) ­ verification and inspection consisting of the use of special laboratory appliances such as mechanical and electrical gauging and measurement; Test (T) ­ this procedure involves established scientific procedures and principles. In the authors' opinion, in contrast to the traditional approach focusing on design convergence as soon as possible Agile delivers working code with business value in each iteration and welcomes change with each new story. In order to achieve emergent design automated testing is essential and with regards to iterative development and verification the practices of; a) daily builds; integration which is done every day and every morning as each programmer checks out the latest copy of the code from the trunk (central repository baseline) and b) continuous integration which is an advancement on daily builds where programmers check in their changes to the trunk many times a day are the most important of technical practices. The emergent design approach can eradicate repetitive and timeconsuming tests and the ability to have automated testing that is introduced at unit and story levels via continuous integration provides benefits that outweigh the overheads. The concept of constantly updating the trunk several times a day surely would provide transparency, early risk mitigation and quality. V. CONCLUSION The main objective of this paper was to evaluate the problems associated with systems development of Agile technical practices for developing IoT solutions for sustainable urban environments. The concept selection stage of a project was referenced for its key activities for implementing Agile framework. The use of Agile methodologies for developing SMART Cities embedded systems and infrastructure, presented the client requirements of a team that is self-organized and manageable. This type of development process allows the team to fully own their problems and embrace the certainty of failure at a very early stage in a projects life cycle. The paper also reviewed the most common techniques of Agile such as Kanban vs Scrum as part of a team's intent based on iterations and increment value for integrating and testing software development. Table 3, compared the differences between traditional tracking techniques to Agile, and while a quantitative metric was not valued the performance analysis did suggest the use of both methodologies. The distributed automated system architecture provided an insight in to the challenges associated with using Agile development on a mobile access infrastructure for controlling electrical, mechanical and security systems. The two most prominent roles of; Scrum master and program manager were presented in order, to highlight the cross-functional attributes of Agile development. The final section `Testing Analysis' recommended focusing on Agile's ability to deliver working code with business value in each iteration that welcomes change with each new story. In the authors' opinion a Hybrid model of different techniques adds transparency, early risk mitigation and quality to software development.
ACKNOWLEDGMENT The author; Alan Martin Redmond would like to acknowledge Dr. Rashed Iqbal at `UCIrvine Division of Continuing Education' for his excellent course on Agile Development.
REFERENCES
[1] INCOSE, "Systems Engineering Handbook; A Guide for System Life Cycle Processes and Activities," 4th Edition, INCOSE-TP-2003-002-04, Published by John Wiley & Sons, Inc., Hoboken, New Jersey, 2015
[2] SAFe, "SAFe® 4.0 Introduction: Overview of the Scaled Agile Framework® for Lean Software and Systems Engineering, A Scaled Agile," Inc. White Paper July 2016, provided by SCALEAGILE, scaledagileframework.com / scaledagile.com
[3] Northen, C., Mayfield, K., Benito, R. and Casagni, M.. Handbook for Implementing Agile in Department of Defense Information technology Acquisition, The MITRE Corporation, 2010
[4] Sutherland, J. and Sutherland, J.J.. Scrum The Art of Doing Twice the Work in Half the Time, published by Crown Business, 2014, www.crownpublishing.com
[5] Cohn M. Succeeding with Agile: Software Development using SCRUM, Addison-Wesley, 2010.
[6] Amabile, T,M., and Khaire, M., "Creativity and the Role of the Leader." Harvard Business Review 86, no. 10 (October 2008).
[7] Bin Adnan, A.N., Bin Jaffar, A., Binti Yusoff, N. and Binti Abdul Halim, N.H., Implementation of Just in Time Production through Kanban System, Industrial Engineering Letters, ISSN 2224-6096 (paper) ISSN 2225-0581 (online), 2013. Vol 3, No. 6. www.IISTE.org
[8] Wikipedia contributors. "Kanban" Wikipedia, the free encyclopedia,
accessed
Web
17
Jan
2017,
https://en.wikipedia.org/wiki/Kanban#cite_note-12
[9] Cutler, T.R. "Examining Lean Manufacturing Promise". 2006. SoftwareMag.com. Retrieved January 29, 2013.
[10] Hiranabe, K . Visualizing Agile Projects using Kanban Boards, INFOQueue, 2007. https://www.infoq.com/articles/agile-kanban-boards accessed 17 Jan 2017
[11] Marschall, M. Kanban vs Scrum vs Agile, Agile Web Development & Operations, July 27, 2015, https://www.agileweboperations.com/scrumvs-kanban accessed 20 Jan 2017
[12] Greenfield, A. Against the Smart City, The Architectural League's Urban Omnibus, The Culture of City Making, 2013. http://urbanomnibus.net/2013/10/against-the-smart-city/ accessed 18 Jan 2017
[13] Uckelmann, D., Isenberg, M., Teucke, M., Halfar, H., Scholz-Reiter, B. "An integrative approach on Autonomous Control and the Internet of Things". In Ranasinghe, Damith; Sheng, Quan; Zeadally, Sherali. Unique Radio Innovation for the 21st Century: Building Scalable and Global
RFID Networks. Berlin, Germany: Springer. 2010. pp. 163­181. ISBN 978-3-642-03461-9 [14] Research EU. Energy-Efficient Solutions for High Performance Computing, research'eu results magazine, IT and Telecommunications, Published by The Community research and development Information Services (CORDIS), 2016. No.57/November 2016, p32 [15] ETSI. Group Specification, Next Generation Protocols (NGP); Scenarios Definitions, ETSI GS NGP 001 V1.1.1, Published by ETSI, 650 Route des Lucioles F-06921 Sophia Antipolis Cedex ­ FRANCE, 2016. [16] GSMA and Network 2020, Unlocking Commerical Opportunities from 4G Evolution to 5G, 2016. p30, www.gsma.com/network2020. [17] Ross, A. and Williams, P. financial management in construction contracting, published by John Wiley & Sons Ltd. 2013. [18] Turner, R. Towards Agile Systems Engineering Processes, CROSSTALK The Journal of Defense Software Engineering April 2007, http://static1.1.sqspcdn.com/static/f/702523/9242881/1288744595590/2 00704-Turner.pdf?token=MaVjkllCscaZrayvu986M0N6JCc%3D, accessed 20 Jan 2017 [19] Forsberg, K., Mooz, H. and Cotterman, H., Visualizing Project Management, 3rd Ed, Hoboken, NJ: John Wiley and Sons, Inc. 2005. [20] Boehm, B., Lane, J., Koolmanojwong, S. and Turner, R. The Incremental Commitment Spiral Model: Principles and Practices for Successful Systems and Software, Boston, MA: Addison-Wesley Professional. 2014. [21] Tridium. Niagara IT Managers Guide, A White Paper, 2011. http://wenku.baidu.com/view/4910282c915f804d2b16c1d2 [22] Tridium. Niagara Networking & Connectivity Guide, Vykon by Tridium, Technical Publications, Niagara Release 2.3, Revised: May 22, 2002, http://www.tridium.com [23] Wasson, C.S. Formulation and Development of the Wasson System Engineering Process Model, ASEE-Southeast Section Conference, 2012. http://se.asee.org/proceedings/ASEE2012/Papers/FP2012was181_589.P DF accessed 20 Jan 2017 [24] O'Grady, J. System Verification, Proving the Design Solution Satisfies the Requirements, Published by Academic Press, an Imprint of Elsevier. 2007.

AM Redmond¹, A Zarli

File: the-concept-selection-of-lean-software-and-system-engineering.pdf
Title: untitled
Author: AM Redmond¹, A Zarli
Published: Sat Jun 10 04:48:47 2017
Pages: 8
File size: 0.44 Mb


The sun rising, 8 pages, 1.45 Mb

Expectations, 4 pages, 0.74 Mb

Annexure-III, 33 pages, 0.34 Mb
Copyright © 2018 doc.uments.com